Note: This is a public test instance of Red Hat Bugzilla. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback at
Bug 1464497 - [Wayland] pop-up menu is automatically focused by mouse
Summary: [Wayland] pop-up menu is automatically focused by mouse
Alias: None
Product: Fedora
Classification: Fedora
Component: firefox
Version: rawhide
Hardware: Unspecified
OS: Unspecified
Target Milestone: ---
Assignee: Martin Stransky
QA Contact: Fedora Extras Quality Assurance
Depends On:
Blocks: ffwayland
TreeView+ depends on / blocked
Reported: 2017-06-23 14:54 UTC by Martin Stransky
Modified: 2017-07-29 07:20 UTC (History)
5 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Last Closed: 2017-07-29 07:20:50 UTC
Type: Bug

Attachments (Terms of Use)

System ID Private Priority Status Summary Last Updated
Mozilla Foundation 1377084 0 P3 NEW Update gtk grab to 3.20 - replace gdk_pointer_grab() by gdk_seat_grab() 2020-03-25 15:27:50 UTC

Description Martin Stransky 2017-06-23 14:54:13 UTC
Description of problem:

When pop up menu is opened (View->Toolbars for instance) and a sub-menu is opened, the sub-menu has automatically cursor mark even when mouse stays on old menu.

Comment 1 Martin Stransky 2017-06-26 15:13:36 UTC
It seems to be caused by mouse grab which is targeted to the newly opened popup window. I don't know why the grab is not performed on X11.

Comment 2 Martin Stransky 2017-06-29 11:30:09 UTC
That seem to come from gdk_seat_grab() - it's the same as on X11. 
Upstream bug:

Some note about Wayland/grab:
It is possible to grab the pointer, which means that all pointer events will go to the grab window for the duration of the grab. Normally pointer events go to the window the pointer is inside. 
You should grab the pointer, for example, if the user is using click-and-drag selection to select a rectangular area. If they click and then inadvertently drag the pointer outside the window, you should continue to track the pointer's location and change the selection accordingly. The grab also ensures that pointer events won't be sent to other applications.         

<garnacho> stransky: AFAIR you should get a GdkEventGrabBroken with event->grab_broken.keyboard=TRUE if the keyboard goes grabbed into a different window. But you need to actually grab the keyboard device too
<stransky> garnacho, okay. a dumb question - how can I recognize that I have the grab? If I remove the grab call from the code I don't see any difference
<stransky> or why do I need that? For menu/popups
<garnacho> stransky: it can't behave the same :), Try clicking outside the window while the popup is shown, for example.
<stransky> garnacho, yes, I'd need to test various scenarios for that
<garnacho> stransky: as for the "why I do need it", some background on gdk_seat_grab(): in X11 making a "popup" consists of "show window;grab pointer;grab keyboard", in wayland it roughly is "create surface;set it as grabbing;show it". So in X11 there are intermediate inconsistent states, while in wayland the operation is performed atomically on the last one, gdk_seat_grab() conciliates both.
<garnacho> on wayland it doesn't do a much "grabbing" itself, except on the client side. its main role is giving a single API entry that does all at once.
<stransky> I see. I'd need to adapt existing code to the atomic show&grab and handle the focus because FF does not expect it and when gets focus out it closes the showed popup

Comment 4 Martin Stransky 2017-07-29 07:20:50 UTC
let's leave it with the subsurface implementation.

Note You need to log in before you can comment on or make changes to this bug.