- From: James Robinson <jamesr@google.com>
- Date: Tue, 29 Jul 2014 09:15:30 -0700
- To: Anne van Kesteren <annevk@annevk.nl>
- Cc: Philip Jägenstedt <philipj@opera.com>, Vincent Scheib <scheib@google.com>, Daniel Cheng <dcheng@google.com>, WHATWG <whatwg@whatwg.org>, Robert O'Callahan <rocallahan@mozilla.com>, Adam Barth <w3c@adambarth.com>
On Tue, Jul 29, 2014 at 8:46 AM, Anne van Kesteren <annevk@annevk.nl> wrote: > On Tue, Jul 29, 2014 at 5:29 PM, Adam Barth <w3c@adambarth.com> wrote: > > Given that you haven't produced a black-box experiment that > > distinguishes the two approaches, different implementations can use > > different approaches and be interoperable. > > I guess. That still doesn't help us much defining it. However, I'm not > convinced that just because I can't come up with an example, there is > none. > > B is nested through A. A invokes requestFullscreen() and then does > synchronous XMLHttpRequest, locking its event loop. B also invokes > requestFullscreen(), posts a message to A about updating its state. > A's synchronous XMLHttpRequest stops, it updates its state per B, and > then gets to the point of putting its own element fullscreen. The end > result is something that the current specification deems impossible > which seems bad. > The race you describe is possible today if you assume A and B are collaborating by communicating with servers that can talk to each other. It's even true if A and B are loaded into different tabs or different browsers completely. A invokes requestFullscreen() or requestPointerLock() or anything else that touches a machine-global resorce and then sends a message over the network to A's server which forwards to B's server which forwards to B. B then invokes requestWhatever() with the 'knowledge' that its invocation has a happens-after relationship with A's, even though in practice A's requestWhatever() may not have propagated through the browser sufficient to touch the shared resource (i.e. ask the OS for fullscreen support / pointer lock / whatnot). This isn't new, but it's so rare and convoluted that I really doubt it ever happens in practice. A more practical sort of race of this nature can happen with NPAPI plugins which in multi-process browsers are a shared, global resource. Chrome (and I believe other multi-process browsers as well) do not run the event loops for different tabs referencing the same plugin in lockstep, so it's very easy for otherwise unrelated tabs to communicate information to each other through a plugin. This can include cross-origin pages if the plugin's same-origin policy is relaxed or relax-able as it is in some cases. It is theoretically possible to construct all sorts of cases where the behavior is black-box distinguishable from running all such tabs in lockstep with each other, but in practice nobody cares. I strongly suspect the situation with cross-origin iframes is similar. While you can construct scenarios where different frames communicate with each other through various channels and come up with answers that seem to contradict knowledge about shared global state, in practice it won't matter. In practice one frame will 'win' and one will 'lose', both will run the appropriate promise handler, and both will continue executing normally. > I guess what needs to happen is that when requestFullscreen() is > invoked it needs to do synchronous checks and those need to be done > again just before the document changes state. And the only check that > involves out-of-process <iframe> (nested browsing contexts) will block > I guess, but that only needs to be made at the initial invocation I > think. > You could, of course, come up with a synchronous checking scheme similar to the storage mutex but barring somebody discovering a significant web compat issue I suspect that, as with the storage mutex, it would be completely ignored by all vendors. - James > > > -- > http://annevankesteren.nl/ >
Received on Tuesday, 29 July 2014 16:15:55 UTC