<html> <head> <base href="https://bugzilla.gnome.org/" /> </head> <body> <div> <a class="bz_bug_link bz_status_NEW " title="NEW - [wayland] second click goes to previously right clicked item in titlebar" href="https://bugzilla.gnome.org/show_bug.cgi?id=776232#c10">Comment # 10</a> on <a class="bz_bug_link bz_status_NEW " title="NEW - [wayland] second click goes to previously right clicked item in titlebar" href="https://bugzilla.gnome.org/show_bug.cgi?id=776232">bug 776232</a> from <a href="page.cgi?id=describeuser.html&login=carlosg%40gnome.org" title="Carlos Garnacho <carlosg@gnome.org>"> Carlos Garnacho</a> <pre>(In reply to Olivier Fourdan from <a href="show_bug.cgi?id=776232#c9">comment #9</a>) > (In reply to Carlos Garnacho from <a href="show_bug.cgi?id=776232#c8">comment #8</a>) > > FWIW, I had this protocol patch to further define the behavior on compositor > > grabs: > > <a href="https://lists.freedesktop.org/archives/wayland-devel/2016-November/031884">https://lists.freedesktop.org/archives/wayland-devel/2016-November/031884</a>. > > html > > Yes, that would clarify the behavior, but also requires a change in the > compositor. Right, that could be. > > > Which, except for wl_touch, is just additional documentation. Your patch > > looks correct and is not too different from what's being done in other > > places, but maybe we should go ahead and try to break implicit grabs on > > wl_pointer.leave? > > Thing is, the issue seems to be pretty much specific to the case of the > window menu, because the window menu is mapped by gnome-shell, thus a > different client to the one that initiated the action. This is one of the cases observed there :) (or at least I intended to). The idea is that it doesn't really matter why a client will stop receiving pointer events, it would be *always* notified through wl_pointer.leave, despite the existence of grabs, or the current button(s) state. So, with this in mind, all of move/resize/show_window_menu requests should immediately trigger a wl_pointer.leave, as the compositor took over control of the pointer. Currently there's no such guarantees, so the client doesn't really know if the request was honored (eg. has a right serial) or not, until maybe the next enter/motion/button event. > > So I am not sure we really need to break implicit grabs on pointer leave in > all cases, at least it works for most cases but the (external) window menu > afaics. TBH I can't see why :), on the compositor side the implicit grab on the surface actor is broken to all effects, it's just the client which isn't notified. > > The patch would be at least an intermediary fix without risk of breaking > much else (as limited to the window menu invocation) at least until a wider > consensus is found (and implemented in the clients/compositors) - Trigering > the wrong action is quite unexpected for the user, even is very limited to > the use of header bar and window menu :) Sure, as said I see nothing wrong with the patch, just that I would like these "grab transfer" situations to be more consistent.</pre> </div> <hr> You are receiving this mail because: <ul> <li>You are on the CC list for the bug.</li> </ul> </body> </html>