See also #2711, #2716, #5049. It would be wonderful if someone could help drive this constellation of issues to a conclusion through specs tests (might need to be manual).

My guess at a model that might work is an explicit per-TLBC boolean "has system focus", with the restriction that only one TLBC will ever have the boolean set to true.

(Maybe per BC would be simpler for spec authors, with it automatically false for non-TLBCs? E.g. the sensors spec could say "if Window X's BC has system focus" and have that always be false for nested BCs.)

Then we'd need to define the interaction of that flag with window.focus(), window.blur(), document.hasFocus, document.activeElement, and the underlying spec concepts.

If a tab/window does not have the system level focus (i.e. it is not the topmost one), window.focus() is able to give it system-level focus if there is a user activation.

How does this work? User activation will focus the tab/window anyway, right? Or are you saying that user activation in window1 can cause window2 to become focused?

In Chrome, window.focus() is not synchronous. This is unlike what the spec says:

Sounds like something that would benefit from cross-browser testing. E.g. if Chrome is in the minority, then we should change Chrome; if it's in the majority, then we should change the spec.

Note that this whole area might benefit from multi-OS testing, so it'll be good to stand up test cases at public URLs with easy instructions for how to run them, so that others can chip in to contribute test results. (I can help with Windows!)

cc @hsivonen

@domenic In Chrome cross-origin focus requests go through the browser process (may be same for same-origin too, not sure). Do we ever want a blocking call that involves two renderers and the browser? I guess no.

We don't, but we should define an API contract that does not depend on process isolation decisions made in individual implementations. So either it always queues a task, or it only queues a task cross-origin/-domain/site, or ...?

I can't opine on this without writing test cases. The problem is I'm not even sure what the full spectrum of issues is to know what set of test cases I should write.

If someone already has test cases, please let me know.

One challenge in testing is that we don't have an API to know if a tab has system level focus.

Right, as I said above, manual tests might be necessary.

See also #2711, #2716, #5049. It would be wonderful if someone could help drive this constellation of issues to a conclusion through specs tests (might need to be manual).

My guess at a model that might work is an explicit per-TLBC boolean "has system focus", with the restriction that only one TLBC will ever have the boolean set to true.

I'd caution against putting such an artificial restriction based on the behaviors of existing popular operating systems. It's possible that a future platform would support having multiple windows in the system to be in simultaneously in focus.