Fix Version/s: None
- 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
on rightMouseButtonUp the pane should get into pressed state and then the sysmenu should open up
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.
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:
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:
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.