1935022 - Ctrl+tab switches to the wrong tab (started taking the mouse position into account)

Status: RESOLVED FIXED

(Firefox :: Tabbed Browser, defect, P3)

Description

[Markus Stange [:mstange]]

Steps to reproduce:

1. Be on macOS.
2. On about:config, set browser.ctrlTab.sortByRecentlyUsed to true.
3. Open two additional tabs.
4. Position your mouse somewhere halfway between the top and the bottom of the screen.
5. Press and hold Ctrl, press Tab, keep holding Ctrl.
6. Once the Ctrl+Tab panel appears, release Ctrl.

Expected results:
You should be switched to the most recently-used tab, regardless of where your mouse is when the panel appears.

Actual results:
You are switched to the tab which the panel displays under the mouse.

---

This is a regression from https://hg.mozilla.org/integration/autoland/rev/3613fc672c501bd6280abfe58e1f53e72f2cd5de .

Emilio, can you take a look?
It might well be that the new behavior is "correct" from the widget / platform side and that the frontend-side workaround needs tweaking.

Comment 1

[Donal Meehan [:dmeehan]]

Setting 133 to disabled since Comment 0 mentions a pref change.
Not sure if this is something needed for 134.
:emilio you have a pending NI already, maybe you would also know if these needs a fix in time for Fx134?

Comment 2

[Mathew Hodson]

The pref browser.ctrlTab.sortByRecentlyUsed is exposed in the settings UI as the "Ctrl+Tab cycles through tabs in recently used order" checkbox under General > Tabs, so this is a bug in a released feature.

This isn't the same as a feature that's only enabled in Nightly behind a flag.

Comment 3

[Donal Meehan [:dmeehan]]

Too late for Fx133.
There is a pending NI for :emilio already and this was triaged as S3
The final beta for Fx134 builds tomorrow so it's too late for Fx134 beta also. Not sure if it should be considered in a later Fx134 dot release or should wait until Fx135.

Comment 4

[Emilio Cobos Álvarez (:emilio)]

Sorry for not replying to this earlier. I confirmed that this is broken on Linux and intermittently on Windows already.

We could tweak the synthetic mousemove timing or something but I think it'd be more reliable if we could do something like showing the panel with pointer-events: none and remove it once the mouse starts moving.

Problem there would be how to detect the mousemove if the panel is outside of the firefox window tho...

Comment 5

[Emilio Cobos Álvarez (:emilio)]

Maybe something like starting with pointer-events: none, then wait for two animation frames (to make sure the synthetic mousemove event is dispatched), then remove the pointer-events...

Comment 6

[Dão Gottwald [:dao]]

Attachment: Bug 1935022 - Wait for two animation frames before tracking mouse movement in the ctrl-tab panel. r?emilio

Comment 7

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/c4f7406bf06c
Wait for two animation frames before tracking mouse movement in the ctrl-tab panel. r=emilio

Comment 8

[Norisz Fay [:noriszfay]]

https://hg.mozilla.org/mozilla-central/rev/c4f7406bf06c