[PATCH wayland] server: Make serial number 0 mean invalid

[Jasper St. Pierre]

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.

On Tue, Oct 13, 2015 at 9:48 AM, Bill Spitzak <spitzak at gmail.com> wrote:
> On 10/08/2015 01:00 PM, Daniel Stone wrote:
>>
>> Hi,
>>
>> On 8 October 2015 at 08:27, Jonas Ådahl <jadahl at gmail.com> wrote:
>>>
>>> On Mon, Oct 05, 2015 at 12:04:49PM -0500, Derek Foreman wrote:
>>>>
>>>> There are cases in weston where it would be quite nice to have a
>>>> sentinel value to use instead of having to have a bool for "this serial
>>>> number is legit" too.
>>>
>>>
>>> Even though probably unlikely, for clients unaware of a possible 0 == no
>>> serial, this would mean that they would suddenly start to be killed when
>>> when they before worked just fine.
>
>
> Clients cannot be killed when they pass bad serial numbers. They don't
> really know what events the compositor accepts for a present request, so
> passing the wrong one cannot kill it.
>
> I suppose a compositor could record the serial number of every event sent to
> the client so it could make sure the request only contained actual ones, but
> I don't think anybody is going to implement a compositor that way. I expect
> compositors will check to see if the event is the last mouse-down or
> mouse-up sent to the client and not remember any other history.
>
>>> Is it really a big deal to have to multiple requests that do things
>>> differently?
>>
>>
>> Let's try to solve this empirically, then - which optional-serial
>> requests do we have apart from present/needs-attention here, and what
>> does/would the difference look like semantically?
>
>
> I agree that if there really is different behavior then there should be two
> requests.
>
> But, do you really, really, really believe that any actual usable compositor
> is going to treat the no-event present differently than a serial for an
> event that should not raise the window (such as a mouse enter event)?
>
> If you think so, please describe carefully exactly why. Since hostile
> clients can call the no-event request, stopping them is not a reason.
> Non-hostile clients will avoid sending nonsense events to the present
> request.
>
> I don't think this will happen, therefore the need for two calls here is
> false.
>
>
> _______________________________________________
> wayland-devel mailing list
> wayland-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/wayland-devel



-- 
  Jasper