On Tue, Jul 29, 2014 at 5:14 AM, Anne van Kesteren <ann...@annevk.nl> wrote: > On Tue, Jul 29, 2014 at 9:51 AM, Daniel Cheng <dch...@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