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

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.

I'm not sure I understand the significance of the synchronous XHR.  I
don't see what would change about your example if it were removed.
There doesn't appear to be any known ordering between the two
requestFullscreen calls and A only learns about what happens to B
asynchronously.

> 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.

I don't think that's the case.

Have you started your implementation of out-of-process iframes?  Some
of these issues are easier to grapple with once you're deeper into the
implementation.

Adam

Received on Tuesday, 29 July 2014 16:03:07 UTC