(In reply to comment #0)
> System Environment:
> --------------------------
> Distro: Fedora 17
> Arch: x86_64
> wayland (HEAD) 1.1.91-0-g3f3671e
> fontconfig (master) heads/master-0-gcbf06d7
> drm (HEAD) libdrm-2.4.45-0-g63aeae1
> mesa (9.1) heads/9.1-0-g26f802d
> libxkbcommon (HEAD) xkbcommon-0.3.0-0-g27a1176
> pixman (HEAD) pixman-0.30.0-0-g41daf50
> cairo (HEAD) 1.12.14-0-g0dac37c
> weston (HEAD) 1.1.91-0-g46cb4a9
> 
> Detailed Description:
> -----------------------------
> Segfault will happen if subsurfaces client is maximized and minimized a few
> times.
> 
> A context menu should pop up, but nothing does.
> 
> Steps to Reproduce:
> ----------------------------
> 1. start weston under X11 or DRM mode
> 2. ./weston-terminal (or any demo)
> 3. Maximize window
> 4. Minimize window
> 5. GOTO 3. until segfault of client occurs

Ignore the bit that talks about a context menu, bug should read as follows:

System Environment:
--------------------------
Distro: Fedora 17
Arch: x86_64
wayland (HEAD) 1.1.91-0-g3f3671e
fontconfig (master) heads/master-0-gcbf06d7
drm (HEAD) libdrm-2.4.45-0-g63aeae1
mesa (9.1) heads/9.1-0-g26f802d
libxkbcommon (HEAD) xkbcommon-0.3.0-0-g27a1176
pixman (HEAD) pixman-0.30.0-0-g41daf50
cairo (HEAD) 1.12.14-0-g0dac37c
weston (HEAD) 1.1.91-0-g46cb4a9

Detailed Description:
-----------------------------
Segfault will happen if subsurfaces client is maximized and minimized a few times.

Steps to Reproduce:
----------------------------
1. start weston under X11 or DRM mode
2. ./weston-terminal (or any demo)
3. Maximize window
4. Minimize window
5. GOTO 3. until segfault of client occurs

I've only been able to observe this bug using the DRM back end.

Created attachment 82297 [details]
Backtrace of segfault in subsurfaces client

Created attachment 82299 [details]
Recreating the segfault

I realize this is a bit ambiguous, so I've included a video of how to easily re-create this segfault.

Okay input->focus_widget is NULL here.

Also window_find_widget() is returning NULL so input_set_focus_widget is overriding the existing focus widget.

The problem is that the motion event is being received after the client has switched to it's minimized dimensions and thus the widget is not being found when we call window_find_widget() and then we override the focussed widget.

   32 [1946197.672]  -> wl_surface@24.frame(new id wl_callback@18)
   31 [1946197.694]  -> wl_drm@17.create_prime_buffer(new id wl_buffer@29, fd 9, 101, 101, 875713089, 0, 512, 0, 0, 0, 0)
   30 [1946197.737]  -> wl_surface@24.attach(wl_buffer@29, 0, 0)
   29 [1946197.751]  -> wl_surface@24.damage(0, 0, 101, 101)
   28 [1946197.767]  -> wl_surface@24.commit()
   27 [1946197.845]  -> wl_surface@22.frame(new id wl_callback@35)
   26 [1946197.870]  -> wl_buffer@51.destroy()
   25 [1946197.914]  -> wl_shm_pool@49.destroy()
   24 [1946197.960]  -> wl_shm@7.create_pool(new id wl_shm_pool@47, fd 10, 41208)
   23 [1946197.985]  -> wl_shm_pool@47.create_buffer(new id wl_buffer@30, 0, 101, 102, 404, 0)
   22 [1946198.387]  -> wl_surface@20.frame(new id wl_callback@40)
   21 [1946198.405]  -> wl_buffer@27.destroy()
   20 [1946198.512]  -> wl_shm_pool@32.destroy()
   19 [1946198.542]  -> wl_shm@7.create_pool(new id wl_shm_pool@34, fd 11, 480000)
   18 [1946198.565]  -> wl_shm_pool@34.create_buffer(new id wl_buffer@50, 0, 400, 300, 1600, 0)
   17 [1946204.055]  -> wl_surface@22.set_opaque_region(wl_region@44)
   16 [1946204.095]  -> wl_region@44.destroy()
   15 [1946204.106]  -> wl_surface@22.set_input_region(wl_region@48)
   14 [1946204.118]  -> wl_region@48.destroy()
   13 [1946204.129]  -> wl_surface@22.attach(wl_buffer@30, 0, 0)
   12 [1946204.154]  -> wl_surface@22.damage(0, 0, 101, 102)
   11 [1946204.182]  -> wl_surface@22.commit()
   10 [1946204.191]  -> wl_surface@20.set_opaque_region(wl_region@16)
    9 [1946204.204]  -> wl_region@16.destroy()
    8 [1946204.213]  -> wl_surface@20.set_input_region(wl_region@41)
    7 [1946204.225]  -> wl_region@41.destroy()
    6 [1946204.235]  -> wl_surface@20.attach(wl_buffer@50, 0, 0)
    5 [1946204.258]  -> wl_surface@20.damage(0, 0, 400, 300)
    4 [1946204.285]  -> wl_surface@20.commit()
    3 [1946204.295]  -> wl_subsurface@25.set_desync()
    2 [1946204.304]  -> wl_subsurface@23.set_desync()
    1 [1946204.315] wl_display@1.delete_id(37)
13467 [1946204.330] wl_pointer@42.motion(3442215001, 966.000000, 7.000000)

So questions I have are:

- Is it expected to receive the motion event outside the dimensions - the pick must have happened on the original surface.
- Are we simply missing a wl_display_dispatch_pending (non blocking) before setting up the changes to the window to get all the events handled?
- Should we simply reject motion events that come outside the window allocation? in window.c

I posted a patch to the list which solves this by filtering out the events.

This patch was integrated:

commit 5f087746ee00573fb8e067d3c25ec2b608e1ffe1
Author: Rob Bradford <rob@linux.intel.com>
Date:   Thu Jul 11 19:41:27 2013 +0100

    window: Disregard motion events outside our current surface dimensions
    
    It is possible to receive a motion event that was generated by the
    compositor based on a pick of a surface of old dimensions. This was
    triggerable on toytoolkit clients when minimising. The new window
    dimensions were propagated through the widget hierarchy before the event
    was dispatched.
    
    This issue was triggering a segfault due to the focussed widget being
    lost as the client code tried to identify which widget should have the
    focus using co-ordinates outside the dimensions of the surface.
    
    https://bugs.freedesktop.org/show_bug.cgi?id=66795

Verified as fixed.