<div dir="ltr"><div>In the xdg-shell thread recently, Pekka had a lot of concerns of the kind "what happens when the client makes an unexpected or illegal request. Should it be an error?"<br><br>I have an answer for this: Any behavior not defined is undefined behavior.  If it's not explicitly mentioned in the protocol, it's undefined behavior.<br>
</div><div><br></div><div>Undefined behavior means that anything can happen. The compositor can send you a fatal error. It can mess up your objects in undetectable ways. The surface contents you present might now be garbage. Obviously, compositors should try *very* hard to catch all edge cases and send protocol errors, but it might be difficult or impractical that we can catch all cases.<br>
<br>As a quick example, we have been discussing "surface roles" in the past week with xdg_surface. Unfortunately, Weston doesn't properly mark cursor or DND surfaces as having roles, and there's no easy way to check for it in the codebase.<br>
<br><div>From my reading of the code, it seems what would happen is that the cursor would disappear as the desktop-shell code changes the surface's position, and on the next mouse move, the cursor would reappear as a wl_pointer.enter event is sent out over the new surface.<br>
</div><br>Obviously, no valid program should ever try to reuse a cursor surface as an xdg_surface.<br></div><div><br></div><div>Thoughts?<br></div><div><br></div><div><div><div>-- <br>  Jasper<br>
</div></div></div></div>