Re: [whatwg] Fullscreen API and out-of-process iframe
On Mon, Jul 28, 2014 at 8:16 PM, Adam Barth w...@adambarth.com wrote: I meant a black-box experiment (i.e., no access to browser internal state). Put another way, can you describe a sequence of events in which the author or the user could observe the difference? If not, then the question is moot. Well if both A and B invoke requestFullscreen() that's obviously for different elements. The observable difference would be which element ends up being fullscreen of course and which call would either fail or end up overwriting the other depending on how we decide to deal with this. -- http://annevankesteren.nl/
Re: [whatwg] Fullscreen API and out-of-process iframe
Either: 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. Daniel​ On Mon, Jul 28, 2014 at 11:56 PM, Anne van Kesteren ann...@annevk.nl wrote: On Mon, Jul 28, 2014 at 8:16 PM, Adam Barth w...@adambarth.com wrote: I meant a black-box experiment (i.e., no access to browser internal state). Put another way, can you describe a sequence of events in which the author or the user could observe the difference? If not, then the question is moot. Well if both A and B invoke requestFullscreen() that's obviously for different elements. The observable difference would be which element ends up being fullscreen of course and which call would either fail or end up overwriting the other depending on how we decide to deal with this. -- http://annevankesteren.nl/
Re: [whatwg] Fullscreen API and out-of-process iframe
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. -- http://annevankesteren.nl/
Re: [whatwg] Fullscreen API and out-of-process iframe
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
Re: [whatwg] Fullscreen API and out-of-process iframe
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 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/
Re: [whatwg] Fullscreen API and out-of-process iframe
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
Re: [whatwg] Fullscreen API and out-of-process iframe
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. The race you describe is possible today if you assume A and B are collaborating by communicating with servers that can talk to each other. It's even true if A and B are loaded into different tabs or different browsers completely. A invokes requestFullscreen() or requestPointerLock() or anything else that touches a machine-global resorce and then sends a message over the network to A's server which forwards to B's server which forwards to B. B then invokes requestWhatever() with the 'knowledge' that its invocation has a happens-after relationship with A's, even though in practice A's requestWhatever() may not have propagated through the browser sufficient to touch the shared resource (i.e. ask the OS for fullscreen support / pointer lock / whatnot). This isn't new, but it's so rare and convoluted that I really doubt it ever happens in practice. A more practical sort of race of this nature can happen with NPAPI plugins which in multi-process browsers are a shared, global resource. Chrome (and I believe other multi-process browsers as well) do not run the event loops for different tabs referencing the same plugin in lockstep, so it's very easy for otherwise unrelated tabs to communicate information to each other through a plugin. This can include cross-origin pages if the plugin's same-origin policy is relaxed or relax-able as it is in some cases. It is theoretically possible to construct all sorts of cases where the behavior is black-box distinguishable from running all such tabs in lockstep with each other, but in practice nobody cares. I strongly suspect the situation with cross-origin iframes is similar. While you can construct scenarios where different frames communicate with each other through various channels and come up with answers that seem to contradict knowledge about shared global state, in practice it won't matter. In practice one frame will 'win' and one will 'lose', both will run the appropriate promise handler, and both will continue executing normally. 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. You could, of course, come up with a synchronous checking scheme similar to the storage mutex but barring somebody discovering a significant web compat issue I suspect that, as with the storage mutex, it would be completely ignored by all vendors. - James -- http://annevankesteren.nl/
Re: [whatwg] Fullscreen API and out-of-process iframe
Can you explain what experiment you could run to determine whether (2) happens synchronously or asynchronously? Adam On Jul 28, 2014 9:03 AM, Anne van Kesteren ann...@annevk.nl wrote: There's two things the Fullscreen API does: 1. Resize the top-level browsing context's document's viewport. (I.e. resizing the window of the browser.) 2. Change state of that document and its descendant documents. 1 needs to happen asynchronously. 2 needs to happen from a task per-document. Potentially 2 could happen from a task per unit of related browsing contexts, but I'm not sure if that's better. 2 also needs to be synchronized with animation frames, once we figure out how to define that. (How are animation frames synchronized across iframe boundaries?) I don't really see a way to avoid having a global flag across process boundaries. E.g. if B is nested through A (assume allowfullscreen is set), A and B are cross-origin, and both invoke requestFullscreen(), what happens? (YouTube embedded in some other app.) Anyone with a good idea how we could make this work? There's some background on some of this available here: * https://www.w3.org/Bugs/Public/show_bug.cgi?id=26366 (It's possible to go fullscreen with an element not in the document) * https://www.w3.org/Bugs/Public/show_bug.cgi?id=26440 (Allow fullscreenchange events to be synchronized with animation frames) -- http://annevankesteren.nl/
Re: [whatwg] Fullscreen API and out-of-process iframe
On Jul 28, 2014 10:58 AM, Anne van Kesteren ann...@annevk.nl wrote: On Mon, Jul 28, 2014 at 7:42 PM, Adam Barth w...@adambarth.com wrote: Can you explain what experiment you could run to determine whether (2) happens synchronously or asynchronously? I'm not sure I understand the question. Do you mean if you can observe that the tasks in different documents might run at the same time? I don't think you could observe that. The problem I have is addressing the racing issues with this API. I meant a black-box experiment (i.e., no access to browser internal state). Put another way, can you describe a sequence of events in which the author or the user could observe the difference? If not, then the question is moot. Adam
Re: [whatwg] Fullscreen API and out-of-process iframe
On Mon, Jul 28, 2014 at 9:03 AM, Anne van Kesteren ann...@annevk.nl wrote: (How are animation frames synchronized across iframe boundaries?) requestAnimationFrame specifies that the callback fires for all iframes within the same task, but it's not black-box observable between cross-origin iframes so it doesn't matter. - James
