So the spec cancels a navigation by changing the ongoing-navigation, which is an ID set on the "navigable", and checked towards the end of a navigation, as part of updating the session history entry.
So it's hard to see how such a setup would fit into Servo's implementation, because the way the spec works is that it queues a task back on the "navigable's active window" to do that last step of the navigation, and then it loads a document.
So at the point of loading a document, the spec is on the event-loop of the window of the document which was navigated; but in Servo at that point we may actually be on the event-loop for the document which is the result of the navigation. So that makes it hard to check for that "ongoing navigation" Id, since that would have been set on something in a different event-loop(script-thread).
Also note that in some cases, it is as part of "loading a document" that the spec creates a new event-loop, as part of create and initialize a Document object, which calls into obtain a browsing context to use for a
navigation response, which in some cases calls into create a new top-level browsing context and document. (this by the way appears wrong to me, because creating the top-level bc invovles manipulation of "per user-agent" data structures, which I don't think can be done from a task running on an event-loop).
So it's not all clear to me, but I'd say the main difference is that the spec "switches on an event-loop" much later than Servo, making it hard to implement certain logic.
So the spec basically switch between tasks on the event-loop where the navigation originated, to in-parallel steps, and back to the original event-loop, and only then in some cases switches to another event-loop(for cross origin navigations).
But Servo does the following:
- Start a navigation in scrip-thread A.
- This Send message to constellation(which asks for permission from embedder to navigate).
- If navigation allowed: load_url
- This creates a new pipeline, which either re-uses an event-loop, or creates a new one, depending on a host check and the bc group(this is the "switch on an event-loop" that the spec does much later).
- It also adds a pending session history change
- Spawning a new pipeline either:
- Sends a new layout to an existing event-loop, which contains a load-data for the fetch.
- Starts a new script-thread(if no event-loop matched above), also with a load-data for the fetch.
- In both cases, this loads the target of the navigation(fetch, parser and so on) from a script-thread.