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

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