Navigation API

[domenic]

Request for Mozilla Position on an Emerging Web Specification

• Specification Title: Navigation API
• Specification or proposal URL: https://github.com/wicg/navigation-api / incomplete spec at https://wicg.github.io/navigation-api/ (HTML PR: Add the navigation API whatwg/html#8502)
• Mozillians who can provide input (optional): @annevk and @smaug---- have been very helpful discussing this so far

[smaug----]

I think the core of the API is rather good, although it shouldn't be called App History, since it is used also for other navigations
(WICG/navigation-api#83)
And personally I'm definitely not a fan of event.respondWith().

But overall the proposed API is definitely saner than the old session history API :)

[domenic]

FWIW, respondWith() definitely needs a rename now, even more so than it did before: WICG/navigation-api#94 (comment)

[samthor]

An update: the API now calls the aforementioned method transitionWhile(), see #151.

[domenic]

The rename has happened; this is now the navigation API!

[smaug----]

Getting the session history in a bit better shape in HTML spec is requirement for this. whatwg/html#8620 is at least rather blocking issue.

[domenic]

Hi @smaug----,

As discussed at the triage meeting, I'm interested in helping with whatwg/html#8620. We decided there the next step was for you and/or @petervanderbeken to investigate; per whatwg/html#8786 (comment)

Olli: this is a longer term task. The spec algorithms will need changes and need to test first all the implementations. Panos will take it off the agenda for now, while Olli investigates.

Has the investigation made any progress?

Personally, I don't think it should be a blocker for the navigation API itself. Although I understand the general sentiment of wanting to clean up tech debt before proceeding with new features, I was hoping that the >40 issues we solved with whatwg/html#6315 would be enough to get us some goodwill there. Do you think Mozilla would be able to give a position on the navigation API before your investigations are complete?

At this point the specification PR to HTML is complete at whatwg/html#8502, so I'd love to get a sense of whether we can check the "Mozilla is interested" box :).

[smaug----]

@domenic have you investigated how Navigation API behaves or perhaps rather should behave when underlying session history is limited.
I would have expected the issue to show up when it was implemented, but perhaps we're missing some tests?

[domenic]

We have, to some extent. The answer comes in two parts:

• How can the navigation API cause truncation? Here the answer is the same as with location.assign(), history.pushState(), etc. All the same edge cases occur, e.g. the one you pointed out in Session history entries list is assumed to be unlimited in size whatwg/html#8620 (comment) , just with analogous APIs. Any changes we make will apply equally to all APIs involved, and any tests we write do not need to be navigation API specific. (Although maybe we should add some using the navigation API for good measure.)

• What happens to the NavigationHistoryEntry objects exposed by the navigation API, when the session history entries are discarded due to this truncation? The answer here is that they should stop appearing in navigation.entries(), and dispose events should be fired. This will involve an algorithm similar to the ones in this section, which contains various algorithms for updating navigation.entries() and firing dispose if necessary. So far it contains ones for coming out of bfcache ("reactivation"), and same-document navigation; it would contain a slightly different one for session history trimming due to limits. We have a tentative test for this at https://github.com/web-platform-tests/wpt/blob/9618c695692cdf0abcdcea5c921603976ccd3a7b/navigation-api/per-entry-events/dispose-for-full-session-history.tentative.html (although I notice it could test that the entry is actually gone, not just that it fires dispose---we'll get right on that).

Hope this helps, and again, looking forward to working with you all on getting this fully specced!

[domenic]

Hi folks, is there anything else I can do to help get Mozilla's position on this API? Apart from the lack of clarity on multi-implementer interest, the spec PR is about ready to land, having gone through a few rounds of review.