You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
#2657 has some ideas on how to do a better job here, although even that is not entirely correct. To fix whatwg/dom#221 properly we need to know ahead of time what kind of Document object to create.
But the rough outline of creating a global, then creating the appropriate document and initializing it, and then replacing the old document if still needed, is probably right. We can even allocate the global and document and throw them away later based on metadata, but the only case where that makes sense is the XML namespace-based dispatching, and it's not clear to me that actually works (see #2656).
It seems ideally navigate goes async, then at some point once we have a response we queue a task that creates the new global, document, unloads the old, and then replaces old with new, all in the same task. The current setup with multiple tasks seems rather weird and likely wrong.
(Note that it might have to become more complicated since the task for the new document could be a distinct task from unloading the old document if we cross agent boundaries. Baby steps though.)
The text was updated successfully, but these errors were encountered:
Fixes#2455 by passing the creation URL to "set up a window
environment's settings object", instead of having it attempt to grab the
creation URL from the not-yet-created Document object.
The later comments in #2455 discuss some followup work we could do to
clarify the Document/Window relationship, but that is left for a future
commit.
This also removes the XXX box mentioned in #2688, since Documents are
nowadays created after Windows in the spec.
#2657 has some ideas on how to do a better job here, although even that is not entirely correct. To fix whatwg/dom#221 properly we need to know ahead of time what kind of
Document
object to create.But the rough outline of creating a global, then creating the appropriate document and initializing it, and then replacing the old document if still needed, is probably right. We can even allocate the global and document and throw them away later based on metadata, but the only case where that makes sense is the XML namespace-based dispatching, and it's not clear to me that actually works (see #2656).
It seems ideally navigate goes async, then at some point once we have a response we queue a task that creates the new global, document, unloads the old, and then replaces old with new, all in the same task. The current setup with multiple tasks seems rather weird and likely wrong.
(Note that it might have to become more complicated since the task for the new document could be a distinct task from unloading the old document if we cross agent boundaries. Baby steps though.)
The text was updated successfully, but these errors were encountered: