Uploaded image for project: 'Core ReactOS'
  1. Core ReactOS
  2. CORE-11324 Some apps does not have active button on taskbar
  3. CORE-16353

explorer must activate a taskbar pane before invoking the sysmenu, not afterwards

    XMLWordPrintable

    Details

    • Type: Sub-task
    • Status: Open
    • Priority: Major
    • Resolution: Unresolved
    • Fix Version/s: None
    • Component/s: None
    • Labels:
      None

      Description

      Reproduction steps

      • open cmd
      • click with the left mouse button on the desktop to transform cmds taskbar pane into unpressed state
      • now click with the right mouse button to cmds taskbar pane

      Expected result
      on rightMouseButtonUp the pane should get into pressed state and then the sysmenu should open up
      2k3sp2_activates_The_Pane_BEFORE_invoking_the_SysMenu.webm

      Observed result
      on rightMouseButtonUp the sysmenu opens up, while the pane remains in unpressed state erroneously. And only when the sysmenu closes, the pane gets into pressed state.
      That is too late.
      0.4.12-RC-55-g3a6cb85__erroneously_activates_the_pane_AFTER_invoking_the_SysMenu.webm
      Please notice that cmds pane is erroneously in pressed state in the end, although my last click was with the left mouse button to the desktop.

      ------------------
      Why is that important you ask?
      Well it will lead to follow up issues quickly, because it introduces concurrency where no concurrency needs to be, and therefore I guess we see the following random behavior in more complex scenarios:

      Take 2 very well-behaving apps: "rapps" and "cmd" and just invoke the sysmenu in an alternating way for both, all the time just using the right mouse button:
      2k3sp2_activates_The_Pane_BEFORE_invoking_the_SysMenu_2apps.webm
      0.4.12-RC-55-g3a6cb85__erroneously_activates_the_pane_AFTER_invoking_the_SysMenu_2apps_randomAlready.webm
      ros behaves here pretty chaotic already when just watching the panes states.
      Remember that opening the next sysmenu here and dealing with its activation-requests and SetForegroundWindow-requests happens at the same time as the old SysMenu is closed and fiddles these states at the same time.

      Let's be even more mean and use the (tricky) DiskGenius setup:
      2k3sp2_activates_The_Pane_BEFORE_invoking_the_SysMenu_2apps_tricky.webm
      0.4.12-RC-55-g3a6cb85__erroneously_activates_the_pane_AFTER_invoking_the_SysMenu_2apps_tricky_random.webm
      total chaos in ros!

      I guess we can avoid that concurrency and chaos altogether if we would first change the panes state and then open the sysmenu, not the other way round.

        Attachments

          Issue Links

            Activity

              People

              • Assignee:
                bug zilla Bug Zilla
                Reporter:
                reactosfanboy reactosfanboy
              • Votes:
                2 Vote for this issue
                Watchers:
                2 Start watching this issue

                Dates

                • Created:
                  Updated: