Re: [whatwg/fullscreen] Decide whether to resize synchronously in requestFullscreen() (#64)

> Is this queue in the same process/thread as the rendering engine, i.e. can you inspect its state synchronously in `requestFullscreen()`?

Yes, yes.

> Are you currently synchronizing "apply the fullscreen request" with animation frames, or does it happen whenever the resize is reported to be done?

Not really. In Gecko, in case `resize` is true, "apply the fullscreen request" happens as soon as we get the message from the window manager that the window size has been changed, but the fullscreen event and resize event is delayed to the next animation frame. If the `resize` is false, we queue a task to "apply the fullscreen request", and dispatch the event in the next animation frame.

I think the difference between this behavior and doing everything in the next animation frame is probably observable, but should be hard to detect in practice, so it may not worth fixing in either spec side or Gecko's impl.

FWIW, I guess we would fix this gap in Gecko when we implement `Promise` for `requestFullscreen`.

> Yes, keeping track only of topLevelDoc would for for #33. Using pendingDoc amounts to a pretty harmless restriction though, so I wouldn't mind aligning with that if it'd be simpler for you.
> I don't think it's possible to move documents, here's a test that shows that moving an iframe causes its document to change: https://software.hixie.ch/utilities/js/live-dom-viewer/saved/4693

Given these, I would be happy that the spec just uses the pending document :)

> In addition to all of the above, can you elaborate on how exiting works? Do exits also end up in the same queue, and how are competing requests and exists handled? I would like the spec to match Gecko in #63, so if you have a good model we can just copy it exactly :)

No, exits just go immediately, and they are even synchronous if `resize` is false... (I probably should at least make them asynchronous in the same way `requestFullscreen` does.) I considered establishing a standalone exiting queue for resolving `Promise`s, but haven't got a clear idea about the details.

Oh, and in `requestFullscreen`, "set resize" happens asynchronously as well... which is probably bad. Given this inconsistency on behavior between request and exit fullscreen, we probably don't want to spec the exactly same algorithm.

I don't think we have any explicit handling of competing requests and exits. I think the two phases resize ("set `resize`" synchronously and "resize viewport" asynchronously) should be fine enough to spec.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/whatwg/fullscreen/pull/64#issuecomment-263059800