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: | firefox | Assignee: | Martin Stransky <stransky> |
Status: | CLOSED RAWHIDE | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
Severity: | unspecified | Docs Contact: | |
Priority: | unspecified | ||
Version: | rawhide | CC: | 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
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. 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 https://github.com/stransky/gecko-dev has a workaround for that - https://github.com/stransky/gecko-dev/commit/eeb9fcaac07c02939033f4ba09c313c7c54cd273 let's leave it with the subsurface implementation. |