- From: Daniel Cheng <dcheng@google.com>
- Date: Mon, 28 Jul 2014 11:03:23 -0700
- To: Anne van Kesteren <annevk@annevk.nl>
- Cc: Robert O'Callahan <rocallahan@mozilla.com>, WHATWG <whatwg@whatwg.org>, Philip Jägenstedt <philipj@opera.com>, Adam Barth <w3c@adambarth.com>, Vincent Scheib <scheib@google.com>
Caveat: I'm not really familiar with the fullscreen API implementation in Chrome. I imagine the synchronous checks would be implemented with a sync IPC from the requesting renderer to the browser (which implies the browser process must keep track of the fullscreen enabled flag and whether or not the fullscreen element stack is empty on a per-frame basis). I'm not sure what the best approach is to implement step 5 of the requestFullscreen API ( http://fullscreen.spec.whatwg.org/#dom-element-requestfullscreen), but it seems like we could use the browser process to coordinate the work across different renderers (where we walk through the documents list). Any subsequent tasks that need to run in different renderers can probably just all be posted at the same time. As for the racing issues... they don't seem out-of-process iframe specific to me? Perhaps I'm missing something here. Daniel On Mon, Jul 28, 2014 at 10:58 AM, Anne van Kesteren <annevk@annevk.nl> wrote: > On Mon, Jul 28, 2014 at 7:42 PM, Adam Barth <w3c@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. > > > -- > http://annevankesteren.nl/ >
Received on Monday, 28 July 2014 18:04:28 UTC