- From: Anne van Kesteren <annevk@annevk.nl>
- Date: Tue, 29 Jul 2014 17:46:15 +0200
- To: Adam Barth <w3c@adambarth.com>
- 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: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 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. -- http://annevankesteren.nl/
Received on Tuesday, 29 July 2014 15:46:56 UTC