On Tue, Jul 29, 2014 at 8:46 AM, Anne van Kesteren <ann...@annevk.nl> wrote: > On Tue, Jul 29, 2014 at 5:29 PM, Adam Barth <w...@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