[Wayland-bugs] [Bug 789268] [Wayland] Smiley picker attempts to "inhibit shortcuts", results in session-modal dialogue

[gtk+ (GNOME Bugzilla)]

https://bugzilla.gnome.org/show_bug.cgi?id=789268

Carlos Garnacho <carlosg at gnome.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |rob at robster.org.uk,
                   |                            |wayland-bugs at lists.freedesk
                   |                            |top.org
          Component|Composer                    |Backend: Wayland
            Version|3.26.x                      |unspecified
           Assignee|evolution-mail-maintainers@ |gtk-bugs at gtk.org
                   |gnome.bugs                  |
            Product|evolution                   |gtk+
         QA Contact|evolution-qa at gnome.bugs     |gtk-bugs at gtk.org

--- Comment #15 from Carlos Garnacho <carlosg at gnome.org> ---
(In reply to Milan Crha from comment #12)
> (In reply to Jonas Ådahl from comment #7)
> > The date-picker popup, what is it made out of? It sounds like it is not
> > turned into a popup in the GDK backend, but it probably should have.
> 
> It's just one example (see comment #3, it's the e-dateedit.c in the list).
> It is created as a GTK_WINDOW_POPUP GtkWindow:
> https://git.gnome.org/browse/evolution/tree/src/e-util/e-dateedit.c?h=gnome-
> 3-24#n652
> Then it is shown, and the grabs are done, here:
> https://git.gnome.org/browse/evolution/tree/src/e-util/e-dateedit.c?h=gnome-
> 3-24#n1444

Porting to gdk_seat_grab() is still highly recommended :), it makes both
showing the popup window and grabbing the input devices "atomic" from the
caller perspective. The GDK wayland backend can barely make sense of the three
calls done separately.

Seeing that you actually grab both pointer and keyboard (I oversaw that the
GdkDevice::grab vfunc on the keyboard would still trigger shortcut inhibition
despite the pointer grab), a gdk_seat_grab() call on GDK_SEAT_CAPABILITY_ALL
would have resulted on correct behavior.

(In reply to Olivier Fourdan from comment #14)
> I am tempted to say let's use this as a workaround (that will fix evo and
> possibly others w/out breaking other apps that need shortcuts inhibition)
> while the decision to keep or remove the dialog in mutter/gnome-shell is
> left pending?

I'll be more romantic and call it "heuristic" :p, IMHO the dialog is good to
have, but it's unlikely that a popup window actually demands the functionality.

Seeing that it may also happen with the traditional 2 gdk_device_grab() calls,
I think something must be done in GTK+, indeed. Will move the bug there.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/wayland-bugs/attachments/20171027/1cafed0b/attachment.html>