[KDE] Back button history drop-down selection does not properly track mouse position
Categories
(Core :: Widget: Gtk, defect)
Tracking
()
People
(Reporter: spillner, Unassigned)
References
(Blocks 2 open bugs)
Details
Attachments
(4 files)
Versions 144.02 and 145.0.1 exhibit a strange regression relative to 140.5 ESR (and all previous versions that I've used). If I hold a left-click on the Back button long enough for the history drop-down to appear, and then keep the left mouse button held down while I move the pointer, the Firefox UI seems to track my mouse position as being about four list rows above the actual cursor position. In other words, as I mouse over any of the first three history list entries, nothing is selected. As I mouse over the fourth row, I can actually get the hover-over effect on the Forward or Refresh buttons in my toolbar, as though my mouse cursor's vertical position were still over that toolbar, even though it's actually over the fourth row in the drop-down. As I mouse down to the fifth row, the first row in the drop-down is selected, as I mouse to the sixth row, the second row is selected, etc. Due to this anomaly, the bottom four rows in the drop-down cannot actually be selected in this mode. When I release the left mouse button, Firefox jumps to the history entry that was shown as selected, not the one that was actually hovered over.
However, if I hold a left-click on the Back button long enough for the drop-down to appear, then release the mouse button before moving the pointer, the drop-down stays open, as I'm sure was intended. In this mode, the UI indications track with my actual cursor position, i.e. the first entry is highlighted when my cursor is over the first row, the second entry is highlighted when my cursor is over the second row, etc., and all drop-down entries are fully selectable. That's the behavior I'd expect when the button is not released too, and previous versions of Firefox worked that way. Obviously, simply releasing the button when the drop-down appears is a simple workaround, but it goes against a quarter-century of muscle memory.
I'm on Linux x86_64, running under Wayland; I haven't yet tested this behavior on any other platform.
|
||
Comment 1•7 months ago
|
||
The Bugbug bot thinks this bug should belong to the 'Core::Widget: Gtk' component, and is moving the bug to that component. Please correct in case you think the bot is wrong.
|
||
Comment 2•7 months ago
|
||
Can you please create a screencast of it?
https://fedoraproject.org/wiki/How_to_debug_Firefox_problems#Create_screenshot/screencast_for_a_bug_report
Thanks.
Screencast added as requested by Martin.
|
|
||
Comment 4•7 months ago
|
||
Thanks. Can you please try to use mozregression to find the broken commit?
https://fedoraproject.org/wiki/How_to_debug_Firefox_problems#Use_Mozregression_tool
Also please attach your about:support page.
Thanks.
This looks like KDE long-press issue same as Bug 1993660 and Bug 1987057.
I agree, these all look like aspects of the same bug. And even if there's an upstream root cause (KDE Wayland compositor passing focus events differently to GTK applications than to Qt), there must be a way to work around it at application level since older Firefox builds don't exhibit this behavior.
I should have some time this weekend to try to bisect it and see whether there's a simple fix.
|
|
||
Comment 7•7 months ago
|
||
May be also recent Gnome regression: https://bugzilla.mozilla.org/show_bug.cgi?id=1984812#c43
|
|
||
Updated•7 months ago
|
mozregression reports:
3:23.35 INFO: Narrowed integration regression window from [f3e8f920, 62f1dc92] (3 builds) to [aeb150a0, 62f1dc92] (2 builds) (~1 steps left)
3:23.36 INFO: No more integration revisions, bisection finished.
3:23.36 INFO: Last good revision: aeb150a06b3eeeab56a698b26d9a487c891fd7a9
3:23.36 INFO: First bad revision: 62f1dc9218204d41aabac5efc3cb0a2f193dd2d2
3:23.36 INFO: Pushlog:
https://hg.mozilla.org/releases/mozilla-release/pushloghtml?fromchange=aeb150a06b3eeeab56a698b26d9a487c891fd7a9&tochange=62f1dc9218204d41aabac5efc3cb0a2f193dd2d2
|
|
||
Updated•6 months ago
|
|
||
Updated•6 months ago
|
|
Reporter | |
Comment 10•6 months ago
|
||
If this is also showing up in other places and irritating other users, I'm happy to continue bisecting to drill down to a specific commit, but the mozregression documentation is sparse. The first changeset (https://hg-edge.mozilla.org/releases/mozilla-release/rev/62f1dc9218204d41aabac5efc3cb0a2f193dd2d2) listed on the Pushlog page reported above has a git commit link of https://github.com/mozilla-firefox/firefox/commit/e5594e0ee224dbbef728f980ce11d7a17ba6d12d, but when I pass -g e5594e0ee224dbbef728f980ce11d7a17ba6d12d to mozregression I always get the error message
ERROR: The url 'https://hg.mozilla.org/releases/mozilla-release/json-pushes?changeset=e5594e0ee224dbbef728f980ce11d7a17ba6d12d' returned a 404 error because the push is not in this repo (e.g., not merged yet).
A similar error occurs when I try to pass the changeset ID (in this case, 62f1dc9218204d41aabac5efc3cb0a2f193dd2d2) instead of the git hash. I've tried --repo mozilla-central, --repo mozilla-release, and --repo mozilla-integration, and even with -b release and -b autoland, all with the same results. What am I missing to be able to use mozregression at the changeset level?
|
|
||
Comment 11•6 months ago
|
||
Most probably it's a bug in Mutter/KWin compositors which is going to be fixed in new versions of both. It's caused by switch to subsurface popups on Firefox side.
|
||
Comment 13•4 months ago
|
||
(In reply to Martin Stránský [:stransky] (ni? me) from comment #11)
Most probably it's a bug in Mutter/KWin compositors which is going to be fixed in new versions of both. It's caused by switch to subsurface popups on Firefox side.
Indeed, https://invent.kde.org/plasma/kwin/-/merge_requests/8789 fixes this on KWin.
|
|
||
Comment 14•4 months ago
|
||
Turns out, it's not that simple. Different compositors behave differently when it comes to this, because the spec never actually specified anything. See https://gitlab.freedesktop.org/wayland/wayland/-/merge_requests/520 for defining how it's supposed to work going forward.
Either way, there is still a bug in Firefox: While the right mouse button is pressed, KWin sends wl_pointer.leave on the original surface and wl_pointer.enter on the subsurface, so Firefox should be taking into account the subsurface position when processing the input events.
|
|
||
Comment 15•3 months ago
|
||
(In reply to Xaver Hugl from comment #14)
Turns out, it's not that simple. Different compositors behave differently when it comes to this, because the spec never actually specified anything. See https://gitlab.freedesktop.org/wayland/wayland/-/merge_requests/520 for defining how it's supposed to work going forward.
Either way, there is still a bug in Firefox: While the right mouse button is pressed, KWin sends wl_pointer.leave on the original surface and wl_pointer.enter on the subsurface, so Firefox should be taking into account the subsurface position when processing the input events.
We use Gtk3 here - Firefox doesn't watch wl_output changes itself.
|
|
||
Comment 16•3 months ago
|
||
I wonder if other gtk3 apps which use subsurfaces - gedit for instance - are also affected.
Tested gedit right now and it opens the subsurface popup on mouse button up (Firefox opens it on mouse button down).
May be a reason we don't see it there.
|
|
||
Comment 17•3 months ago
|
||
I wonder if we update the mouse coordinates according to an active popup.
|
|
||
Comment 18•3 months ago
|
||
I think wl_output is mapped to Gtk3 enter/leave events so the mouse coordinates are translated accordingly. It's possible that Gtk3 takes wrong popup as active (i.e. uses toplevel as active?) so the coordinates are wrong.
Please run in firefox on terminal as:
MOZ_LOG="Widget:5,WidgetPopup:5" WAYLAND_DEBUG=1 firefox > log.txt 2>&1
reproduce the issue once and attach the log.txt here. It should show how the events are mapped.
Thanks.
|
|
Reporter | |
Comment 19•3 months ago
|
||
Log from the current git tip (commit #8d0f55f3e63334ef6a855d12d756954c7ddb97aa), running under KDE Plasma 6.5.4 and GTK 3.24.51. In the logged run, I hold down the left mouse button over the browser Back button, and continue to hold the left button down while slowly mousing down until the pointer focus eventually moves over an item in the history list (i.e. eventually selects the first (most recent) item in the history, while my cursor is actually over about the sixth item in the list). I then release the left mouse button and close Firefox.
|
|
Reporter | |
Comment 20•3 months ago
|
||
|
|
Reporter | |
Comment 21•3 months ago
•
|
||
A few other potentially informative aspects of the bug that I just noticed--- not terribly surprising, but perhaps they help confirm the underlying defect(s):
(1) When I hold down the right mouse button to get the pop-up context menu, and leave it held, the focus correctly follows my mouse cursor IF AND ONLY IF either (a) the browser window is full-screened, or (b) the pop-up extends past one of the window edges. Otherwise, the mouse cursor cycles the selection between widgets at the top-left of the browser window (e.g. Firefox View, Sidebar, Back/Forward, and Reload buttons), and not the pop-up entries. This is all basically consistent with the discussion in #2007851.
(2) When I hold down the left mouse button over the "Back" button, and scroll my actual cursor past the bottom edge of the pop-up, the focus (as expected) returns to the underlying page (although the pop-up remains visible), and the focus on background page elements correctly tracks actual cursor position. For example, if I navigate to https://en.wikipedia.org/wiki/Firefox and then pop-up a Back history with ten items, the #Security relative link is visible just below the pop-up at my current window resolution and font settings. As I drag my cursor over the first four entries in the history list, nothing is selected. When the cursor gets to about the vertical center of the fifth entry, the first is selected, when over the sixth entry, the second is selected, etc. through the sixth entry being selected when the cursor is actually over the tenth. As soon as I drag the cursor past the bottom of the pop-up and over the #Security link, that link immediately displays as underlined, as though it has mouse/keyboard focus. This suggests that the tracked coordinates are indeed correct with respect to the parent surface. As I continue dragging, the underlined/not underlined status cycles (among links on the underlying page / parent surface) as you would expect during normal mouse-over.
(3) However, mouse button events are not applied to those "moused-over" links. For example, when I release the left mouse button over one of the links, the back-button pop-up remains activated and the link remains underlined. If I left-click again while the cursor is over the link, the pop-up disappears (as expected for a click event outside its boundary) but my browser doesn't jump to the target of the underlined link.
(4) Similarly, when I drag the mouse cursor past the bottom edge of the pop-up as in (2) above, the keyboard focus remains constrained to the pop-up widget, i.e. the up/down arrow keys cycle through the history list, even when my cursor position is causing links on the background page to cycle between underlined/non-underlined status.
I don't know whether (3) and (4) are the intended behavior or not. It seems a little odd to have the mouse cursor "activating" (underlining) links that won't actually receive the next left-click, and to have keyboard buttons cycling through a different set of selections than the mouse cursor, but it's not really annoying in the way that a selection not matching the cursor position (in the pop-up) is. At any rate, it's not part of the same regression from the shift to subsurface rendering; I see the same behavior in older builds (i.e. 140 & previous) that don't have any problem tracking the pop-up selection.
|
|
||
Updated•3 months ago
|
|
|
||
Comment 22•3 months ago
|
||
Can you try latest nightly:
https://fedoraproject.org/wiki/How_to_debug_Firefox_problems#Testing_Mozilla_Nightly_binaries
Please set widget.wayland.force-move-to-rect to true at about:config and restart browser and try again.
Thanks.
|
|
Reporter | |
Comment 23•3 months ago
|
||
Can confirm that fixes the issue on my system, in both the back-button drop-down and right-click context menus. Tested with commit #4bade96.
Thank you for your perseverance on this!
|
|
||
Comment 24•3 months ago
|
||
Okay, Thanks.
Description
•