Skip to content

Task queuing for document creation is sketchy #8443

@domenic

Description

@domenic

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.

Metadata

Metadata

Assignees

No one assigned

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions