1750721 - Page context menu is broken when submenu is visible

Status: VERIFIED FIXED

(Core :: Widget: Gtk, defect)

Description

[gwarser]

Attachment: simplescreenrecorder-2022-01-18_11.50.46.mp4

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:98.0) Gecko/20100101 Firefox/98.0

Steps to reproduce:

• right click on link
• hover over "open link in new container"
• now try clicking other entries when submenu is visible

Actual results:

no action on click, submenu hover effect visible when hovering over top menu entries

Comment 1

[gwarser]

9:46.84 INFO: Running autoland build built on 2022-01-17 15:42:57.808000, revision 878272ff
9:54.06 INFO: Launching /tmp/tmpht80t5t2/firefox/firefox
9:54.06 INFO: Application command: /tmp/tmpht80t5t2/firefox/firefox --allow-downgrade -profile /tmp/tmp97lzozeq.mozrunner
9:54.06 INFO: application_buildid: 20220117152243
9:54.06 INFO: application_changeset: 878272ff6da5f40c8a1dd09a73126c9c3e97455e
9:54.06 INFO: application_name: Firefox
9:54.06 INFO: application_repository: https://hg.mozilla.org/integration/autoland
9:54.06 INFO: application_version: 98.0a1
Was this integration build good, bad, or broken? (type 'good', 'bad', 'skip', 'retry', 'back' or 'exit' and press Enter): good
10:15.93 INFO: Narrowed integration regression window from [c55b23cc, 8ec44392] (3 builds) to [878272ff, 8ec44392] (2 builds) (~1 steps left)
10:15.93 INFO: No more integration revisions, bisection finished.
10:15.93 INFO: Last good revision: 878272ff6da5f40c8a1dd09a73126c9c3e97455e
10:15.93 INFO: First bad revision: 8ec44392a6f595889a82cc53e3bfe6219b6829fd
10:15.93 INFO: Pushlog:
https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=878272ff6da5f40c8a1dd09a73126c9c3e97455e&tochange=8ec44392a6f595889a82cc53e3bfe6219b6829fd

Comment 2

[BugBot [:suhaib / :marco/ :calixte]]

The Bugbug bot thinks this bug should belong to the 'Firefox::Menus' component, and is moving the bug to that component. Please revert this change in case you think the bot is wrong.

Comment 3

[BugBot [:suhaib / :marco/ :calixte]]

Set release status flags based on info from the regressing bug 1747919

Comment 4

[Pulse]

I'm seeing the same behaviour on Nightly/Linux with build 20220118124804

Comment 5

[Robert Mader [:rmader]]

Thanks for the report. This appears to only happen on X11 and is likely caused by https://phabricator.services.mozilla.com/D134793. Apparently there are slightly different semantics between gdk_display_get_window_at_pointer() and gdk_device_get_window_at_position() or I overlooked something.

Comment 6

[Robert Mader [:rmader]]

Turns out it was actually https://phabricator.services.mozilla.com/D134797. That's a bit unfortunate because the replaced gdk_pointer_grab() is still GTK2 API. OTOH, the replacement, gdk_device_grab(), is also already deprecated again. So maybe we can just revert this one and revisit the case once we bump our minimal required GTK version to 3.20. Then we can use gdk_seat_grab().

Before doing that I'll try a little bit if I can get gdk_device_grab() to work.

Comment 8

[Robert Mader [:rmader]]

Attachment: Bug 1750721 - Revert D134797, r=stransky

For some reason gdk_device_grab() does not behave like
gdk_pointer_grab() on X11 - potentially a GTK bug.
As gdk_device_grab() already has been replaced again by
gdk_seat_grab(), let's wait until we can switch to that
instead, i.e. once we require GTK >= 3.20.

Comment 9

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/811c4760de98
Revert D134797, r=stransky

Comment 10

[Atila Butkovits]

https://hg.mozilla.org/mozilla-central/rev/811c4760de98

Comment 11

[Virgil Sangerean]

Reproduced issue on Ubuntu 20 on X86 build from 18.01.2022.

Issue is no longer reproducible on 98.0b8 Firefox latest beta.