Ubuntu UX

Bug #1398852
Comment #7

Comment 7 for bug 1398852

Revision history for this message

Allison Karlitskaya (desrt) wrote on 2015-04-02: Re: Need a mechanism to prevent focus stealing

> 1. Why would checking each apps' queue for focus grants, before opening a window, be "exceedingly unreasonable"?

It's not because it would be a massive amount of work to do this, but rather because of how awkward it would be to do it from the place that it needed to be done. I imagine the Mir server to be structured in a way where incoming requests from a client result in some code being run to handle those requests. You'd now be in a situation where that code would have to go and actively check for pending incoming requests from all other clients (while in the middle of handling a request), potentially selectively dequeuing some things from those other clients (ie: grant requests) from a place other than where they are normally dequeued. It's not just a simple matter of checking the queue -- you'd have to actively interact with the kernel. It's not that this is computationally complex or slow -- it's just that it would be extremely awkward.

> 2. I don't know where "Presumably an app is allowed to focus new windows of its own without going through the grant mechanism" comes from.

Sure. This is a presumption. It wouldn't have to be done this way, but if you didn't do it this way, you could get a worse evil: opening a new window in my web browser would then give a chance for an arbitrary popup from another app to sneak in.

> 3. I understood that the timestamp mechanism worked only in simple cases in some toolkits. I see how it works in gdk_app_launch_context_set_timestamp(), for example, but where do you put the timestamp in Qt's activateWindow() function? [...]

The timestamp is not typically treated explicitly by most toolkits, but rather implicitly. They record the timestamp of the most recent incoming event, internally, and when making requests to the X server, they give the most-recent-timestamp automatically. The APIs that allow you to explicitly specify the timestamp are only required in cases where you are "doing something strange", such as opening a window on behalf of a request from another program (rather than a direct input event to your program). The most common cases of this (application launching, and using the shell to create new windows in existing apps) are even handled automatically via the _TIME field in the startup notification ID.

This might seem a bit "evil", but the truth is that 99% of the time, you get something that 'just works' without the programmer having to think about it. Only when they are doing weird things do they have to be aware that they need to deal explicitly with this stuff. We even give a nicer alternative, in GApplication, to allow the use of GActions for sending arbitrary requests between processes, and if you use this, the timestamp stuff is still handled automatically for you. That's a convenience -- people should always be given the ability to deal with it manually if they want to.

> 1. Why would checking each apps' queue for focus grants, before opening a window, be "exceedingly unreasonable"?

It's not because it would be a massive amount of work to do this, but rather because of how awkward it would be to do it from the place that it needed to be done.  I imagine the Mir server to be structured in a way where incoming requests from a client result in some code being run to handle those requests.  You'd now be in a situation where that code would have to go and actively check for pending incoming requests from all other clients (while in the middle of handling a request), potentially selectively dequeuing some things from those other clients (ie: grant requests) from a place other than where they are normally dequeued.  It's not just a simple matter of checking the queue -- you'd have to actively interact with the kernel.  It's not that this is computationally complex or slow -- it's just that it would be extremely awkward.

> 2. I don't know where "Presumably an app is allowed to focus new windows of its own without going through the grant mechanism" comes from.

Sure.  This is a presumption.  It wouldn't have to be done this way, but if you didn't do it this way, you could get a worse evil: opening a new window in my web browser would then give a chance for an arbitrary popup from another app to sneak in.

The timestamp is not typically treated explicitly by most toolkits, but rather implicitly.  They record the timestamp of the most recent incoming event, internally, and when making requests to the X server, they give the most-recent-timestamp automatically.  The APIs that allow you to explicitly specify the timestamp are only required in cases where you are "doing something strange", such as opening a window on behalf of a request from another program (rather than a direct input event to your program).  The most common cases of this (application launching, and using the shell to create new windows in existing apps) are even handled automatically via the _TIME field in the startup notification ID.

This might seem a bit "evil", but the truth is that 99% of the time, you get something that 'just works' without the programmer having to think about it.  Only when they are doing weird things do they have to be aware that they need to deal explicitly with this stuff.  We even give a nicer alternative, in GApplication, to allow the use of GActions for sending arbitrary requests between processes, and if you use this, the timestamp stuff is still handled automatically for you.  That's a convenience -- people should always be given the ability to deal with it manually if they want to.