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

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.


-- 
http://annevankesteren.nl/

Received on Tuesday, 29 July 2014 12:14:40 UTC