Tracking issue for rebasing on top of the navigation and session history rewrite

[domenic]

whatwg/html#6315 rewrites much of the foundational standard that this spec is built on top of.

The eventual goal (on the order of a month or two) is to merge that PR into HTML, and then merge this spec into HTML. In the meantime, we need to make sure it's relatively clear how to implement this spec.

The current status is that this spec is built on a mixture of the live HTML Standard, an older revision of the session history rewrite, and (after #220) the latest revision of the session history rewrite. This is a pretty confusing state of affairs.

We can mitigate that via two parallel routes:

• Mitigation
  • Have discussion and scratch-notes on this issue about how things are supposed to fit together, despite the spec not being clear
  • Write lots of web platform tests
• Do the work
  • I.e., continue rebasing this spec on top of the session history rewrite, until it is completely rebased
  • This process will probably compete for resources with the project of landing the rewrite itself, and then migrating this spec to HTML

I am relatively confident that despite the current spec situation being subpar, it will not lead to new interop problems. I.e., I don't think there is anything about the rebasing that will require significant cross-browser discussion. There are some things in the rewrite themselves, at the foundational level, that are not interoperable, and will benefit from discussion, but how this spec fits on top of the rewrite is, in my judgment, pretty clear from the current spec text.

For example, the exact structure of a "session history entry" will change between the live HTML Standard and the session history rewrite. But, the idea that it needs to be extended with new fields will work the same before and after.

Similarly, in the rewrite, reloading is changing from using the navigate algorithm, to using a separate "reload" algorithm. But, it is pretty clear that reloading will in either case synchronously fire a navigate event according to the current spec's algorithms.

If anyone finds areas of the current Navigation API spec unclear in how they are supposed to fit into existing/rewrite infrastructure, please highlight them on this issue and I will fix them ASAP.

[domenic]

Scratch notes about how to do the rebase (will be updated over time as I discover things):

(Here "main thread"/"renderer process" = tasks queued on a Window global; "browser process" = the session history traversal queue)

• "Update the entries" currently synchronously accesses the browsing context's session history, from the main thread, and then computes all the deltas. In the rewrite, you only have access to the active session history entry from the main thread; you have to be in the browser process to call "get the history entries" for a navigable.
  • Fixing this probably means aligning more closely with Chromium's implementation strategy: i.e., have separate "update the entries" algorithms for sync navigations, bfcache reactivations, and new non-initial-about:blank document creations. Then, the latter two can get the relevant data passed in to them from the browser process, whereas the former just makes synchronous updates.
  • Relatedly, we probably shouldn't have each NavigationHistoryEntry directly own a "session history entry" object; those should stay in the browser process. Probably each NavigationHistoryEntry should just get the appropriate data passed in at construction time? The only hard part there is sameDocument.
    • Or maybe this is being too rigorous. Maybe we don't want to specify all the IPCs in detail for, e.g., updating the navigation API state value of a non-current entry. We could just modify the navigation API state of the associated session history entry, and leave the fact that this needs to get synced to the browser process and/or to disk as implicit.
• Related to the above, navigate event firing for traversals is currently based on an old revision of the session history rewrite. After the rebase, it should probably be very close to the "update the entries" calls (but, notably, before we update the active session history entry). Edit: #222 accomplishes this.