-
Notifications
You must be signed in to change notification settings - Fork 3.1k
Description
Basically, when we actually create a new Document and Window object, what event loop are we on?
With the current spec, there's enough confusing thread-hopping that it's not clear, and probably not consistent between traversal and navigation.
After the rewrite (#6315), it's a bit clearer, but it's probably wrong: we queue the task to create these objects, on the previous document's event loop. For example, "attempt to populate the history entry's document" queues a global task on navigable's active window.
This is hard to fix because right now, in the new-agent case, document/window/realm/agent are all created at the same time, in "create and initialize a Document object".
Possible directions for a fix:
-
How much of the stuff in "attempt to populate the history entry's document"'s queued task really needs to be on the main thread anyway? Could we delay the task queueing until much later, when we're about to create a Window/Document object but after we've selected or created the agent/event loop?
-
Move agent/event loops to being created earlier, e.g., when the reserved environment is created.
-
Say that actually, it's fine to create document/window/realm/agent from in parallel, as long as we clearly state what realm the document/window are created in. We just can't run any script there without queuing a task. (I'm skeptical of whether this is legit, especially when it comes to things like modifying the usually-main-thread-only properties of a document or window...)
This is somewhat related to the XXX box at https://html.spec.whatwg.org/#run-a-worker, but that case seems even worse.