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.

[smaug----]

I'll try to find time next week to review the proposal a bit more. There are thing around index handling and NavigateEvent which are a bit unclear to me still. Index handling especially because of the limited session history size (so, I don't know how well the API works in those cases when entries are purged).

[MineDrum]

@smaug---- any update on this? :)

The company I work for is considering using this if firefox plans on supporting it eventually

[petervanderbeken]

@smaug---- any update on this? :)

See the discussion in the PR (whatwg/html#8502).

[domenic]

Is there anything more we can do to move the process forward, from the Chromium side? I think we've answered all the questions ~9 days ago, and from the looks of it most of the engagement is at a fairly low-level. I'm hopeful even if there are remaining issues during the implementation period, Mozilla might be able to decide whether or not they're positive/negative/neutral on the API at this point. Let me know if there's anything else we can do to move that along!

[smaug----]

The review process is just a bit slow. And it is very low level since one needs to check whether the API works with the underlying session history, even with the theoretical fix for whatwg/html#8620
I'd rather avoid to land something to the spec and then realize later that it has significant issues. The new API does after all add some new ways to expose the limits of session history.

I think in general any help with whatwg/html#8620 would be great. That is an issue we have talked about for years, also during the meetings about Navigation API.

[zcorpan]

I've discussed this with @smaug---- and @petervanderbeken

Suggested position: positive

There are various details that we're not sure about in the spec and we'd like to continue reviewing and submit feedback about issues we find. But the API as a whole is a good improvement for implementing SPAs over the status quo.