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

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

From: Adam Barth <w3c@adambarth.com>
Date: Tue, 29 Jul 2014 08:29:02 -0700
Message-ID: <CAJE5ia_C0c4AWJkUJZROr5eFzx9Y15HyiKM5AR=ww9V7vFe21w@mail.gmail.com>
To: Anne van Kesteren <annevk@annevk.nl>
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:14 AM, Anne van Kesteren <annevk@annevk.nl> wrote:
> On Tue, Jul 29, 2014 at 9:51 AM, Daniel Cheng <dcheng@google.com> wrote:
>> 1) The frames attempt no synchronization and both just call
>> requestFullscreen(). In that case, the observable difference is largely
>> moot. It shouldn't be surprising that racing operations like this cross
>> origin returns a non-deterministic result. This is the position the Chrome
>> out-of-process team is taking for other sorts of actions that have effects
>> visible outside the frame (for example, navigating the top level frame,
>> multiple frames sending a postMessage to the same frame, etc).
>>
>> 2) One frame calls requestFullscreen() and then sends a postMessage() to
>> another frame, which calls requestFullscreen() upon receiving the message.
>> Going fullscreen requires coordination with the browser process, so ordering
>> is preserved by browser IPC message handling.
>
> So I tried to figure out how one would implement this in JavaScript as
> an exercise. You'd have a privileged asynchronous API that resizes the
> top-level browsing context's document's viewport. It calls a callback
> once that's done, presumably synchronized with animation frames.
>
> Now at that point you need to get hold of all your ancestor documents
> and start changing state outward-in. Some of these ancestor documents
> you can get a hold of synchronously, but not all. What if there's a
> cross-origin document inbetween?
>
> Now what I'm afraid of is that one of these ancestors or perhaps a
> descendant is also playing with requestFullscreen() and since the
> changing of state does not happen globally you end up with
> inconsistent state.

Given that you haven't produced a black-box experiment that
distinguishes the two approaches, different implementations can use
different approaches and be interoperable.

Adam
Received on Tuesday, 29 July 2014 15:30:08 UTC

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