When I was working on the Fullscreen implementation a while ago, I added an "animation frame task" concept and had the fullscreen code add tasks on that task queue. I agree that a callback that just looks at its own usually-empty task queue is bit odd.

I'm not sure I follow what the problem is here.

There is no serious problem, the current arrangement will work. Fullscreen can define its own queue of pending tasks for the next animation frame and go through this queue on every call to the "run the fullscreen rendering steps" hook.

This bug is asking if instead this queue of tasks could be moved to HTML, so that Fullscreen can simply say "queue an animation frame task"? This means that two specs could both do this, but as long as the algorithm which invokes "queue an animation frame task" runs at a well-defined time, it should not lead to undefined task order.

Provided bug 28876 does not end up changing all of this, I think we could generalize this into "render tasks of type /type/". And then you can "queue a render task of type /type/". And we'll have "render task queues of type /type/". And we'll have a list of "render task types" ("fullscreen" being one of them) that step 8 of the event loop iterates over to empty all their respective render task queues of type /type/, etc.

So I tried to redo this by giving fullscreen a queue of its own. Elsewhere Domenic and I established that not all specifications need a queue here and might need their own logic for such a queue anyway.

However, isn't it still problematic that HTML effectively runs a set of steps on a per-document basis whereas fullscreen needs a callback for a top-level browsing context?

Could the top-level browsing context's document (ignoring all others) be used as an approximation of what you want?

We could ignore all other documents, sure, but that seems very inefficient and an unlikely match for how this would be implemented.

I think that it might be implemented using the same mechanism that's used to sync events to animation frames. In Blink there's a Document::enqueueAnimationFrameEvent, and when I was looking at this some generalization of that was my thinking.

Given the possibility of out-of-process iframes I don't think a single top-level callback would actually work. Maybe registering per-document callbacks in a specific order would end up doing the right thing.

So we'd rephrase https://fullscreen.spec.whatwg.org/#dom-element-requestfullscreen and https://fullscreen.spec.whatwg.org/#exit-fullscreen to iterate over the documents and then queue a task for each of them to fullscreen/unfullscreen and dispatch events? Maybe that is actually fairly reasonable.

Would be quite a rewrite though.

I'm hesitant to say yay or nay without going deeper into the implementation. Xidorn, maybe this is implemented more like the spec in Gecko? WDYT?

In Gecko, the current implementation is that, when the browser window enters fullscreen, the state of the document is changed immediately, and then events are put in an event queue which is currently only used for fullscreen (though has a generalized name). And events in the queue are dispatched in the next animation frame, after animation events and before animation frame callbacks.

It sounds like it is something similiar to Blink's implementation? I guess it is good to standardize this queue with a generalized name.

The document state change being synced with window change (async with the events) is a bit different with what the spec currently says, but that's an issue for the Fullscreen spec.

Treating this as moved to https://github.com/whatwg/html/issues/707