In one case, an invalid serial dictates that the window should have it's focus attempts prevented. In the no-serial case, focus world be stolen. <div class="gmail_quote"><div dir="ltr">On Tue, Oct 13, 2015, 10:25 AM Bill Spitzak <<a href="mailto:spitzak@gmail.com">spitzak@gmail.com</a>> wrote: </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On 10/13/2015 09:53 AM, Jasper St. Pierre wrote: > The goal of focus-stealing prevention isn't to prevent hostile clients > from stealing the focus. It's to allow friendly clients to upgrade the > experience if they can track the originating event that originally > opened a window. For instance, if I launch GIMP but then go back to > typing in a terminal, after GIMP launches, it shouldn't steal the > focus, because I've interacted with another window since then. > > We've tried turning off focus-stealing prevention for all new windows > without a timestamp, and it provided a very unfun experience. Lots of > applications either don't have an originating user action when they > pop up a window, or they don't track it thoroughly. > > Perhaps GUI applications have gotten substantially better in the 6 > years ago since we tried it -- I'd be willing to run the experiment > again. But I don't expect much changing. Yes but this is still not answering my question. Can you describe a design where no-event is treated *differently* than an unknown or disallowed event in the _present request? You are describing how they would be treated identically. I suspect that will always happen, but the idea that they can be treated differently is being used as an excuse to not add the special no-event serial of zero and reduce the number of _present messages from 2 to 1. </blockquote></div>