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 bugzilla.redhat.com.

Bug 1464497

Summary: [Wayland] pop-up menu is automatically focused by mouse
Product: [Fedora] Fedora Reporter: Martin Stransky <stransky>
Component: firefoxAssignee: Martin Stransky <stransky>
Status: CLOSED RAWHIDE QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: rawhideCC: extras-qa, gecko-bugs-nobody, jhorak, kengert, pjasicek
Target Milestone: ---   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2017-07-29 07:20:50 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On:    
Bug Blocks: 1054334    

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

https://github.com/stransky/gecko-dev

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: https://bugzilla.mozilla.org/show_bug.cgi?id=1377084

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 :), https://git.gnome.org//browse/gtk+/tree/gdk/wayland/gdkwindow-wayland.c#n2128. 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.