Bug 1464497 - [Wayland] pop-up menu is automatically focused by mouse
[Wayland] pop-up menu is automatically focused by mouse
Product: Fedora
Classification: Fedora
Component: firefox (Show other bugs)
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: Martin Stransky
Fedora Extras Quality Assurance
Depends On:
Blocks: ffwayland
  Show dependency treegraph
Reported: 2017-06-23 10:54 EDT by Martin Stransky
Modified: 2017-07-29 03:20 EDT (History)
5 users (show)

See Also:
Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2017-07-29 03:20:50 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

External Trackers
Tracker ID Priority Status Summary Last Updated
Mozilla Foundation 1377084 None None None 2017-06-29 09:36 EDT

  None (edit)
Description Martin Stransky 2017-06-23 10:54:13 EDT
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 11:13:36 EDT
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 07:30:09 EDT
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 03:20:50 EDT
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.