Move Callback fires after menu closes when changing focus to another window

[regorxxx]

1. Create menu within panel
2. Alt + tab to other windows, and work on them (wait a few seconds)
3. Alt + tab back to foobar

Result: Button remains on focus, because move callback keeps firing on last position even if panel or windows is not on focus anymore. Note window.IsVisible remains true, but that's wrong. Restoring foobar2000 window does not fix it, until mouse reenters the panel.

Button remains on focus (blue) after alt-tab.

Have added logging to the callbacks: the last ones are after click and alt-tab.

@marc2k3 I suppose this also happens on jscript (?)

[marc2k3]

Maybe update the state of your button/repaint inside on_mouse_rbtn_up before TrackPopupMenu.

If you right click a hyperlink here on github, it remains underlined while the mouse is down. Release to open the menu and the link is no longer underlined.

[regorxxx]

Maybe update the state of your button/repaint inside on_mouse_rbtn_up before TrackPopupMenu.

If you right click a hyperlink here on github, it remains underlined while the mouse is down. Release to open the menu and the link is no longer underlined.

Nope. Move callback is called after TrackPopupMenu; that's the thing. It's called multiple times at times I can't define while being on other windows. Check the console at top. The menu is called at click, all the other move strings correspond to SMP firing a callback when foobar is not even visible (so it obviously overrides anything you do at other places). Have you taken a look at the gif? The mouse is released at the click line (and it works fine up to that point). The rest is just things done by SMP without any logic after menu creation and alt-tab.

I have added as a workaround a position cache, so it only refreshes the button if mouse really moves.

[regorxxx]

Well... you don't even need to use alt-tab, it's the same for non maximized windows. Just clicking outside foobar triggers the problem:

Note how the button loses focus after clicking the menu as it should be, but once the menu closes due to changing windows, the move callback fires at the last position which is totally wrong.

After adding the move check:

[marc2k3]

I really don't understand the mouse move/gifs at all.

But maybe you should change the state of your button from on_focus when is_focused is false ??? This should trigger when you ALT-TAB.

https://theqwertiest.github.io/foo_spider_monkey_panel/assets/generated_files/docs/html/module-callbacks.html#~on_focus

[regorxxx]

Focus is related to mouse clicking first, which has nothing to do with move callback firing when a window is not even active. So even if that "fixes" the problem, so does caching the X,Y position and only doing things when such coordinates change. In any case those are workarounds, the move callback is not working as it should be.

I don't understand what you don't understand from my gifs. First one clearly shows a menu opening and the button being activated after closing a menu and changing the active window to another one. That should never happen. The button is not in focus when opening the menu, and the move callback fires when the window is hidden which is a bug.

Second gifs applies a workaround. And it clearly shows what should happen when you alt-tab or switch the active window.

This gif should clearly display the move callback is not working as intended at all. It makes zero sense that moving the mouse outside foobar and clicking again in foobar, outside the panel, fires the move callback withing the panel when the mouse is not there. It just reuses the last known position.

[regorxxx]

You don't even need to switch windows, it does the same just by moving the mouse out.

[marc2k3]

[regorxxx]

Never mind, this thing was related to some kind of incompatibility with AutoHotkey which was doing strange things with the callbacks. It seems ok after fixing that.