fullscreen

fullscreen copied to clipboard

The current implementation in Gecko is that, the document state (document flag, element state, etc.) is changed immediately when the dimension gets changed. It doesn't really match the current spec.

The reason is that, I think it is more important to always keep the document state consistent with its dimensions.

If we change the window dimensions, but delay the state change to the next animation frame, there is a chance script could detect the intermediate state where the fullscreen flags are not ready but the window dimensions have been changed. The intermediate is not useful at all.

There is also a performance concern that, detecting the intermediate state itself could trigger a resize reflow (e.g. for querying element size). But if we do resize reflow at that moment, we will need another reflow for fullscreen change. Two reflows can be expensive.

I'm not sure I completely follow. I thought the idea was that we'd actually change the dimensions, change the state, and dispatch events / resolve promises as part of that animation frame (specifics to be defined).

The current spec says the dimensions are changed in parallel to the next animation frame, right?

It may not that easy to change dimensions in animation frame, as changing window dimensions is not guaranteed to be sync, and when the window dimensions are changed, there are callbacks to sync the size of documents... And given we've found it hard to align resize event to animation frame, it is probably not easy to do what you are thinking.

In addition, the dimensions of viewport (from Window.{outer,inner}{Width,Height}) is updated synchronously when the size gets changed. Inconsistency between the document state and those properties might also be a problem.

So how does synchronously changing the size from x to y work with a concept of animation?

Also, when does the size change? Does it happen at the moment you invoke the method? For all documents? (What if those documents were in a different process?)

The size is changed at some moment which we probably cannot fully control, but we can do stuff when that happen. That's the point.

When a document is in a different process, the parent process need to tell the child that its size should change, and we can do stuff there.

@upsuper but the size change is synchronized with the main thread somehow. So I guess requestFullscreen() requests a size change, and then a task is queued somewhere to change the size, and then at the next "frame" we dispatch events?

The change is... well, yes, but the timing is unpredictable. e.g. something like

request fullscreen                       window size change finishes
          v                                            v
  |--------------------|--------------------|--------------------|
  ^                    ^                    ^                    ^
vsync                vsync                vsync                vsync

When "window size change finishes", what should happen then? Should we delay everything including size of the viewport to the next vsync? I suppose that may unnecessarily add complexity given we would need to use something to hold the original size for an extra while.

I would be okay with defining that the size changes from a task and that the events are dispatched before the next frame (I'm assuming vsync is frame).