This issue can be triggered more reliably with the gtk3-demo "Combo boxes" demo:

1. Open the "Combo boxes" demo
2. Select the "Where are we" combo box
3. Cycle through each "main" drop-down option ("A-B", "C-D", etc.) by moving/hovering the mouse over each option.  Allow some options to popup there submenus.
4. eventually weston aborts while doing step 3.

This is an interesting flow:

- we're trying to show a popup surface - shell_map_popup
- but then for some reason our client is unresponsive so we call set_busy_cursor
- which then tries to setup a shell grab using shell_grab_start which then tries to end the popup_end_grab
- popup_end_grab checks the invariant: assert(!wl_list_empty(&shseat->popup_grab.surfaces_list)); but because we didn't finish starting the grab this fails

We can fix this by removing the assertion.

The more worrying thing is why is the client unresponsive?

Actually removing the assertion is wrong. We need to move the list insertion before - because otherwise we'll try to add the popup grab that we just tried to remove.

commit dfe310512b4ed8f5dd591611b61a5dfd114403b0
Author: Rob Bradford <rob@linux.intel.com>
Date:   Wed Jun 26 19:49:11 2013 +0100

    shell: Allow ending of popup grabs from within the starting of the grab
    
    Calling weston_pointer_start_grab can lead to a code path (in this case
    when the shell surface is unresponsive) that can try and remove the
    popup grab to setup a shell grab.
    
    Ending the popup grab requires removing the surface from the grab's
    surfaces list - however the grab had not yet been fully setup so the
    grabbed surface was not yet in this list.
    
    With this change we ensure we add the surface to the list before setting
    up the pointer grab.