Comment 6 for bug 1398852

I've just come across this bug report, thanks to Christopher's comment in the spec.

1. Why would checking each apps' queue for focus grants, before opening a window, be "exceedingly unreasonable"? Would it be too slow? The focus decision algorithm wasn't yet written at the time of Ryan's review, but at the moment, checking for a focus grant is step 4 of a 6-step process. A decent fraction of focus requests (for example, all tips, and all children of the previously-focused window) would have exited at earlier steps, so would not require the check.

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. Apart from the case of a child of the currently-focused window (which should always be focused), requests are treated the same regardless of whether they are from the same app or a different app.

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? <http://doc.qt.io/qt-5/qwidget.html#activateWindow> Or in window.open() as called from XUL? <https://developer.mozilla.org/en-US/docs/Mozilla/Tech/XUL/Tutorial/Features_of_a_Window> Or in LibreOffice's Window::ImplGrabFocus()? <http://docs.libreoffice.org/vcl/html/mouse_8cxx_source.html#l00198>

Of course, those toolkits don't do focus grants today either. I'm not particularly attached to the focus grant mechanism; if timestamps can work better, then great! But for timestamps to work, both the trigger app *and* the opening app need to handle them, right? (Even if it's the same app, it needs to do two different things with the timestamp, creating it at the moment of input, and then sending it when requesting focus.) Whereas for the focus grant system to work, only the trigger app would need to handle it. If so, the timestamp system would work less often.