<div dir="ltr"><div><div><div>Hi All,<br></div>After looking into it a bit more, it appears as if the proper thing to do is to allow a null surface in wl_pointer.leave, wl_keyboard.leave, etc.  Right now, that's what the clients are seeing anyway because wl_surface_destroy destroys the associated proxy so there is no valid way to call a wl_pointer.leave handler with a non-null surface.  Allowing that argument to be null with a specific note about surface closing would make how we handle it server-side irrelivant.<br>
<br></div>I'll send a protocol patch some time soon here.<br></div>--Jason Ekstrand<br></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Sat, Jun 15, 2013 at 3:34 PM, Jason Ekstrand <span dir="ltr"><<a href="mailto:jason@jlekstrand.net" target="_blank">jason@jlekstrand.net</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><div><div><div>Hi All,<br></div>This week, some of the wl_resource pointer changes that I made to weston caused a bug related to destroyed resources in keyboard/pointer focus handling.  This bug brings up an interesting protocol issue in how we should handle pointer focus with respect to resource destruction.<br>

<br></div>The specific issue in the code is as follows.  Before, when a weston_surface got destroyed by wl_resourc_destroy, the wl_resource object was left more-or-less intact while the wl_resource.destroy_signal was fired.  In the new changes, the resource gets destroyed (and the pointer set to null) when that signal gets fired.  One of the things that happens due to that signal is firing a wl_pointer.leave event for the closed surface.  Due to the change, the wl_pointer.leave event is fired with a null surface (which causes weston to print a warning).  Also related is a possible segfault.<br>

<br>This brings me to the protocol question.  Shoud we fire a wl_pointer.leave event for a surface if the pointer leaves because the client destroyed the surface?  In theory, the proxy object for the surface should have been destroyed before the client recieves the signal so we really can't handle it properly on the client-side anyway.  Most of the time this doesn't matter because all the demo clients are single-window, but for multi-window clients, it might be an issue if they only close one window.<br>

<br></div><div>Once the protocol questions get answered, I'll fix the bug one way or the other.<br></div><div><br></div>Thanks for your thoughts,<br></div>--Jason Ekstrand<br></div>
</blockquote></div><br></div>