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

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

From: Anne van Kesteren <annevk@annevk.nl>
Date: Tue, 29 Jul 2014 17:46:15 +0200
Message-ID: <CADnb78iCJkJ0HrcVke7XnocgYSwJ9PWtp_Ad50QnufqngLGkig@mail.gmail.com>
To: Adam Barth <w3c@adambarth.com>
Cc: Daniel Cheng <dcheng@google.com>, Robert O'Callahan <rocallahan@mozilla.com>, Philip J├Ągenstedt <philipj@opera.com>, Vincent Scheib <scheib@google.com>, WHATWG <whatwg@whatwg.org>
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

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.

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

Received on Tuesday, 29 July 2014 15:46:56 UTC

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