Comment 8 for bug 1398852

1. I don't buy the "awkward" objection, because dealing with focus grants would be far from the only case where Mir should inspect -- and possibly remove items from -- the request queue. For example, at the moment you start manually resizing a window, Mir should immediately deal with any queued request from the app to close the window, or to change its current, minimum, or maximum size. At the moment you start moving a window, Mir should immediately deal with any queued request from the app to close the window, to resize it (because size constrains how far it can move), or to change its type (because the new type might be unmovable). And at the moment you choose to minimize a window, Mir should immediately deal with any queued request from the app to change its type or parent (because the new combination might be unminimizable).

2. The spec already says that the grant system has the possibility of false positives. But the interloper window might be from the same app -- for example, a popup that your browser's popup blocker failed to catch, or a progress window that your file manager opened because an operation had taken more than a few seconds so far. That's why the focus decision algorithm makes no distinction about what app the new window is from.

3. Oh, just going by last input is clever. I guess pointer movement alone doesn't count as an "incoming event"? If so, the one case I can think of where it might fail is during drags, where an app might know whether a drag was the reason that a window was opening, but its toolkit wouldn't know.

Given all that, if you're still confident that the cookie system is better than focus grants, I'll change the spec accordingly.