Fix history step continuation in a new Window

[domenic]

Closes #9869, by making it clearer that we figure out "navigable's active window" when the steps are run, not when they are declared.

Good commit message to be written once we figure out the right path here

@kalenikaliaksandr, can you take a look and confirm this clarifies the issue?

---

/browsing-the-web.html ( diff )

[kalenikaliaksandr]

This change fixes the problem I described in the issue. Thank you!

[kalenikaliaksandr]

ok, I tried to apply this fix in my implementation and found another issue: the queued task is still never executed because the document associated with newWindow only becomes active once afterDocumentPopulated is complete.

[domenic]

Dang, right, OK.

So I think actually queueing a task might not be necessary at all. Nothing in afterDocumentPopulated needs to run on an event loop. So I think we can just set completionSteps to afterDocumentPopulated. I'll update the PR to do that for now.

However, I think that just delays the issue. The continuation at https://whatpr.org/html/9901/browsing-the-web.html#continuations-dequeue , in step 14.11, has a similar task-queuing issue.

We could try to fix that by moving steps 14.11.1.1-3 out of the queued task. However, a lot of those steps do want to be on the event loop. "Unload" explicitly asserts that. And "Make active" touches a lot of state which is associated with the (new) document, and thus should really ideally be only accessed while on that document's event loop. Hmm.

I guess we have a pretty fundamental conflict here which is that the unload event needs to be fired while the old Document is active, but "attempt to populate"'s whole deal is updating the current entry's document, which makes the old Document inactive.

It seems this problem is unique to reloads, because reloads are the only case where the active session history entry's document is modified in this way.

Do you have any ideas on what might be a better architecture? Would we have to do something dramatic like move away from the paradigm where "attempt to populate" modifies targetEntry? Or is there a more surgical fix? Any thoughts from @domfarolino @jakearchibald?

[domenic]

Closing since this particular fix is unlikely to work; we'll continue discussing potential paths in #9869.