[Wayland-bugs] [Bug 776232] [wayland] second click goes to previously right clicked item in titlebar

[gtk+ (GNOME Bugzilla)]

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

--- Comment #10 from Carlos Garnacho <carlosg at gnome.org> ---
(In reply to Olivier Fourdan from comment #9)
> (In reply to Carlos Garnacho from comment #8)
> > FWIW, I had this protocol patch to further define the behavior on compositor
> > grabs:
> > https://lists.freedesktop.org/archives/wayland-devel/2016-November/031884.
> > 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.

-- 
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/20170111/5d7efcbc/attachment.html>