W3C home > Mailing lists > Public > whatwg@whatwg.org > July 2014

Re: [whatwg] Fullscreen API and out-of-process <iframe>

From: James Robinson <jamesr@google.com>
Date: Tue, 29 Jul 2014 09:15:30 -0700
Message-ID: <CAD73mdKidu9u6MEjCzTBOBev5ZxEwnKxKzm8YBCu5JkJ5R3UzQ@mail.gmail.com>
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

This archive was generated by hypermail 2.4.0 : Wednesday, 22 January 2020 17:00:22 UTC