navigate event timing on history traversals

[domenic]

When working on tests for #137, we noticed something about the Chromium implementation, and I believe about the current spec, which is a bit strange. Which is that, for traversals, we fire navigate events only after getting a response back from the server, i.e. just around unload event time.

This is in contrast to non-traverse navigations, where we fire navigate immediately and synchronously.

Recall that non-traverse navigations and traversals are fundamentally different because traversals can affect many different frames. In particular, one frame can cause multiple other frames (including cross-origin/cross-process ones) to traverse. So traversals are in a crucial sense always async: they go from the initiating frame, up to the main browser process, which potentially does a bunch of network fetches, and only then to they descend into the traversed frames, firing unload and replacing the documents with the new ones. Whereas non-traverse navigations just go to the single destination frame, and navigate it.

In addition to the consistency question between non-traverse and traverse navigations, this is related to #32 and #178. In particular, if we eventually want to make some traversals cancelable, it might make more sense for the event to fire earlier rather than later?

Keeping that desired end state in mind, we basically have three options here:

1. Stick with the status quo for now, of navigate firing late for traversals. In the future, when we want to make it cancelable, move it to fire early, but still async.

   • Implementation-wise, early-but-still-async would require traversals to start in the source frame, go up to the browser process, which then fans out to all potentially-traversed frames to fire navigate events, waits to see if anyone canceled them, then proceeds with the network stuff, before eventually fanning back out to the traversed frames with the results. This is annoying to implement but not impossible, and seems like what beforeunload might be doing already. (Although nobody really thinks beforeunload is a great precedent to build on...)
   • This eventual change would improve consistency somewhat in that navigate would always fire "soon" for both traverse and non-traverse navigations. Even though the former would be async and the latter would be sync, at least neither would be network-dependent, whereas right now traversal navigate timing is network-dependent.
   • This eventual change would have a slight compat risk, but it's very hard to depend on the timing here unless you are doing strange things that correlate the server being hit with your client-side code.

2. Stick with navigate firing late for traversals forever, including in the future when we make traversals cancelable.

   • This is easy to implement for now, as browsers can continue to use their current code paths for firing unload in order to fire navigate.
   • The main downside is lack of consistency between traversals and non-traverse navigations: not only do they differ in sync vs. async, the traversal navigate timing is also network-dependent.

3. Try to hack navigate to fire sync for some traversals.

   • In particular, I think the best we can do is fire it sync for frames that are same-origin-domain to the frame which called history.back() or navigation.traverseTo().
   • This would require some extra implementation work to sync enough data to all frames about whether a given delta would traverse them (and thus they should synchronously fire navigate), or not.
   • For the browser UI back button, sync vs. async isn't meaningful, but it would require similar work to (1) to fire navigate before hitting the server when using the browser back button. So, the browser back button would not be included in this option; only (1) would remove the server-dependent component from that case.
   • This would give some degree of consistency between navigations and non-traverse navigations, at least for developer-initiated traversals? But maybe that consistency is a false, confusing consistency, because developers really should be thinking of traversal as async, even though we can come up with special hacks for same-origin-domain frames.

I think the main near-term question is whether (3) is valuable.

/cc @annevk @smaug---- @japhet as I'm adding this to the "Might block v1" milestone, to decide on whether (3) is worthwhile.

[domenic]

Basically this is a question of what "navigation", and in particular the navigate event, means.

• Is a traversal a sort of navigation?
• Or, is a traversal a different sort of thing which could kick off several navigations?
• If a traversal kicks off several navigations, does the navigation "start" once the server responses have been received, or does it start immediately?

In current browsers the architecture is that a traversal kicks off navigations, and in some sense it only does so after the responses have been received. (I.e., it only reaches into the target frame to trigger its "you're going to be navigated" code after the appropriate response has been received.)

[domenic]

I'm disliking (3).

For (1) vs. (2), i.e., will we fire navigate for traverals "late" vs. "early", @natechapin guided me through some use case analysis:

• Top-frame does a cross-document traversal: all subframes will go away. canTransition will always be false. cancelable is false now but we would like it to be true later. Early means we need to consult the top frame before going to the network.

• Top-frame does a same-document traversal: let's assume no subframes change. canTransition is true. cancelable is false now but we would like it to be true later. Early vs. late is meaningless since we're not going to hit the network.

• Top-frame traverses N descendant frames: canTransition in each subframe may be true or false depending on whether the iframe is traversing cross- or same-document. We think we should keep cancelable false to simplify things; if different iframes can all give input into whether to cancel the traversal, it's very complicated. This means for cross-document-traversing iframes, the navigate event is purely advisory (it has both canTransition and cancelable as false.) So early means it knows it's being navigated before hitting the network; late means it only knows it's being navigated around unload time.

From this perspective, (1) is incurring a lot of complexity in order to give cross-document-traversing subframes non-actionable information sooner, plus give the top-level frame actionable information sooner. (2) is avoiding that complexity at the cost of potentially wasting some network fetching for the top-level frame, if it ends up wanting to cancel navigate.

This opens the possibility of:

4. Make navigate fire early for top-level frames that do cross-document traversals, but let it fire late for subframes that do cross-document traversals.

This is probably a good bit easier to implement than (1), and gives most of the benefit. The cost is an inconsistency between top-level frames and subframes. Although maybe it's OK, since that inconsistency stems from the fact that top-level frames are the only ones that we give control over the traversal...

[annevk]

Is it the top-level document or the navigating document that is the deciding factor? Consider A -> B -> C and B navigates cross-document. Under 4, wouldn't we want navigate to fire early for B?

[domenic]

It depends on why we want navigate to fire early.

• If we want it to fire early because that's more consistent, then yes, it should fire early for B.
• If we want to fire early only in cases where event.cancelable will be true, then firing early for B is not very important. Because we think it's bad to let non-top-frames cancel traversals, so event.cancelable will never be true for such traversals.

[annevk]

But if B itself initiated the traversal? Even then it cannot cancel it? (Admittedly I lost track of the traversal / non-traversal distinction of this issue for a bit, but I think the question still makes sense.)

[domenic]

It basically comes down to how much complexity we are willing to bite off. Is the goal to make everything that can be non-abusively canceled, cancelable? In that case we can indeed get pretty far. E.g. I think you can end up with: any programmatic traversal initiated by a same-origin-domain page, that only traverses same-origin-domain frames higher in the tree or any iframes lower in the tree, and is allowed by all the relevant sandboxing flags, can be canceled without a potential for back-trapping or security problems.

But is that really worthwhile? Will it make sense to developers?

I've been tentatively arguing for a very simple model, where the only cancelable traversals are top-level ones. I think that meets most of the use cases in #32.

(The use cases it doesn't meet that well are for pages where the entire web app is hosted in a full-page iframe. Those would need to have their containing page do the actual navigation API stuff. I think that's OK... if you create such an application architecture, you're probably used to some compromises.)

[annevk]

It might be worth checking with YouTube at least?

[domenic]

We discussed this offline and didn't come to any firm conclusions; everyone was pretty flexible. It felt like the leading candidates were (1) and (4). Since nobody was arguing for (3), I'd like to eliminate it from the running, and thus remove this from the "might block v1" issues list since the compat problems are minimized. (Because the event will always be async, even if we're still discussing the exact timing, i.e. discussing (1) vs. (2) vs. (4).)