Bug 76662

Created attachment 96431 [details]
gdb_backtrace1

Well, I found different ways to reproduce this issue. Weston crashes while selecting any of the client context menu items (Close, Move to workspace above, Move to workspace below ). 

1. Launch any client
2. Try to select any  context menu option  +  mouse click on the workspace or toolbar

*** Bug 76866 has been marked as a duplicate of this bug. ***

It seems the problem is related to the popup grab not ending at the moment the button is released after a menu item was clicked. In popup_grab_button() there's a statement

        if (/* there's focus */) {
               /* send button event */
        } else if (state == WL_POINTER_BUTTON_STATE_RELEASED &&
                   (shseat->popup_grab.initial_up ||
                    time - shseat->seat->pointer->grab_time > 500)) {
                popup_grab_end(grab->pointer);
        }

If that was just two separate 'if' statements, the grab would end at the moment the button is released. I couldn't really figure out why the 'else if' is there looking through the git history, but I take there's something I'm not seeing.

The way it is now, the grab ends only when the destroy animation finishes or the user click somewhere else. In the latter case, if the click is in a surface that belongs to another client, the click event is swallowed.

Fixed in:

commit a46b946cb3842a6e6296ed7c4c7b0303096a2b00
Author: Bryan Cain <bryancain3@gmail.com>
Date:   Fri Apr 4 17:41:24 2014 -0500

    shell: Fix segfault from trying to access a destroyed popup shell surface
    
    The shell_destroy_shell_surface function only set the backing resource to
    NULL, leaving an unusable surface in the popup_grab list until the surface's
    fading animation finished and it could be freed. This caused a segfault if
    the shell tried to forcibly break the grab during that time interval due to
    the compositor losing the keyboard focus.
    
    https://bugs.freedesktop.org/show_bug.cgi?id=77072

(In reply to comment #4)
> It seems the problem is related to the popup grab not ending at the moment
> the button is released after a menu item was clicked. In popup_grab_button()
> there's a statement
> 
>         if (/* there's focus */) {
>                /* send button event */
>         } else if (state == WL_POINTER_BUTTON_STATE_RELEASED &&
>                    (shseat->popup_grab.initial_up ||
>                     time - shseat->seat->pointer->grab_time > 500)) {
>                 popup_grab_end(grab->pointer);
>         }
> 
> If that was just two separate 'if' statements, the grab would end at the
> moment the button is released. I couldn't really figure out why the 'else
> if' is there looking through the git history, but I take there's something
> I'm not seeing.

The first case handles buttons up/down in any of the grab owners surfaces.  This never ends the grab and just sends the event to the client to process.

The else branch deals with button events outside the grab owners windows, which cancels the grab if it's a release event and we've either

  1) seen the release event from the click that triggered the popup, or
  2) it's the release event from the initial click and it comes later than 500ms after the click (click-and-drag menu use case)
 
> The way it is now, the grab ends only when the destroy animation finishes or
> the user click somewhere else. In the latter case, if the click is in a
> surface that belongs to another client, the click event is swallowed.