App history API

[domenic]

HIQaH! QaH! TAG!

I'm requesting a TAG review of the app history API proposal.

The web's existing history API is problematic for a number of reasons, which makes it hard to use for web applications. This proposal introduces a new window.appHistory API, which is more directly usable by web application developers to address the use cases they have for history introspection, mutation, and observation/interception.

The proposed API layers on top of the existing API and specification infrastructure, with well-defined interaction points. The main differences are that it is scoped to the current origin and frame, and it is designed to be pleasant to use instead of being a historical accident with many sharp edges

• Explainer¹ (minimally containing user needs and example code): https://github.com/WICG/app-history/blob/main/README.md
• Security and Privacy self-review²: https://github.com/WICG/app-history/blob/main/security-privacy-questionnaire.md
• GitHub repo (if you prefer feedback filed there): https://github.com/WICG/app-history
• Primary contacts (and their relationship to the specification):
  • Domenic Denicola (@domenic), Google
• Organization/project driving the design: Google
• External status/issue trackers for this feature (publicly visible, e.g. Chrome Status): none yet, will update when we start prototyping

Further details:

• I have reviewed the TAG's API Design Principles
• The group where the incubation/design work on this is being done (or is intended to be done in the future): WICG
• The group where standardization of this work is intended to be done ("unknown" if not known): WHATWG
• Existing major pieces of multi-stakeholder review or discussion of this design: none of this design, although there is a lot of discussion of how the existing history API is bad (which the explainer links to throughout)
• Major unresolved issues with or opposition to this design: no major issues yet. There are a number of minor TODOs scattered throughout the document and issue tracker; thoughts on the best ways of resolving those would be appreciated.
• This work is being funded by: Google

You should also know that...

The intent here is not to provide any substantial new capabilities, but instead provide a more ergonomic and interoperable API for manipulating history. See especially our discussion of interop goals and building this on a solid foundation at the bottom of the explainer's Goals section

We'd prefer the TAG provide feedback as (please delete all but the desired option):

🐛 open issues in our GitHub repo for each point of feedback

[kenchris]

Hi there,

Thanks for filing the issue. We understand the use-cases and problem domain very well and are very happy that you are looking at solving these long standing issues for users. But given the size we will need some more time to look at the details, but so far we are positive.

[torgo]

Further to that, thanks for the comprehensive response to the security and Privacy questionnaire and for the s&p considerations section. This looks great.

[domenic]

Thanks to you both for the kind words! I do understand this is a pretty large explainer, and I apologize for that. We did recently add a summary section and early code examples that might help a bit. Please take all the time you need.

BTW, I realized that

There are a number of minor TODOs scattered throughout the document and issue tracker; thoughts on the best ways of resolving those would be appreciated.

is less than helpful, especially since there's a mix of "TODO fill in this example", "TODO figure out this minor API issue", and "TODO bigger architectural issue". I've pulled out the ones where thoughts would be especially appreciated into the following issues, sorted roughly in order of most-architectural to least-architectural:

• Should we allow more direct control over when the URL bar updates? Will the current transitionWhile() design of updating the URL/history entry immediately meet web developer needs? WICG/navigation-api#66
• What design should be used for reporting navigation duration? What design should be used for reporting navigation duration? WICG/navigation-api#33
• Should this API be able to completely replace window.history and window.location? Should this API be able to completely replace window.history? What about window.location? WICG/navigation-api#67
• Should app history events be fired on page load? Should window.navigation fire events fire on page load? WICG/navigation-api#31

[torgo]

Thanks for the steer, @domenic ! We are picking it up today and hope to have some initial feedback back to you soon.

[torgo]

One thing : slightly concerned whenever we talk about re-writing what is in the URL bar - as there could be potential for mis-use. And there doesn't seem to be a discussion of that in the privacy & security section...

[domenic]

Sorry, that should have been mentioned in that section indeed! It has the same restrictions as history.pushState: can only change the path/query/fragment.

[kenchris]

I managed to get some framework authors to look at this, for instance

WICG/navigation-api#66 (comment)
WICG/navigation-api#66 (comment)

with indication that they will evaluate the proposal further.

[torgo]

@domenic we're just discussing again in our breakout today and one question that came up : is there any indication on multi-engine support at this point?

[torgo]

@domenic we also discussed the 4 issues you pointed us to and considered the feedback already on those issues.

For WICG/navigation-api#66 we think the URL bar should update immediately from a web user experience PoV - can you be more specific about the use cases where you think this would be detrimental? @kenchris left WICG/navigation-api#66 (comment)

Also left the following comments:

WICG/navigation-api#33 (comment)

WICG/navigation-api#67 (comment)

[domenic]

@domenic we're just discussing again in our breakout today and one question that came up : is there any indication on multi-engine support at this point?

We're fairly early in the process and haven't reached out to other engines that much. That said, @annevk and @smaug---- from Mozilla have been engaged and helpful. Getting some more formal expressions of interest is on my radar to do in the near future, as things are starting to settle. (E.g. the spec text is beefing up in a way that makes it easier for implementers to evaluate how this meshes with their existing infrastructure.)

@domenic we also discussed the 4 issues you pointed us to and considered the feedback already on those issues.

Thanks very much!

For WICG/navigation-api#66 we think the URL bar should update immediately from a web user experience PoV - can you be more specific about the use cases where you think this would be detrimental?

My instinct aligns with yours here. However, I suspect there are sites today that consciously choose use the following pattern:

someButton.onclick = async () => {
  const data = await fetchLotsOfData();
  await updateTheDOMMaybeWithSomeCoolAnimations(data);
  history.pushState(null, "", newURL);
};

i.e. they delay updating the URL bar until after the data has fetched and the DOM has updated. So in that issue I'm trying to tease out if there are framework or site authors who are indeed doing that consciously, and get a sense of whether they'd be OK switching to an immediate-update model, or if that would be a blocker for them using app history.

[torgo]

Hi @domenic one thing that came up in the f2f today (and apologies in advance for bike-shedding): we think "App History" is confusing because it implies this is about the history of apps on a device or similar. It feels like this has scope across the web. We don't have a good alternative suggestion... WebAppHistory?

[torgo]

Some more feedback from our f2f discussion: We're happy to see this effort happening. Thanks for listening to our feedback. Adding additional complexity to the web platform remains a problem. We're concerned about adding a new API that has to do with history which developers will find confusing on top of the existing history API. At the same time it's clear that it's meeting a user need. The example of XHR and Fetch came up in our discussion. In that case, it was clear what we were asking developers to do - migrate to Fetch. Can we do the same with this API? So we'd like to better understand how this can be added to the web platform whilst also mitigating against the complexity issue. However we're generally happy to see this go forward.

[domenic]

Thanks for continuing to take a look!

one thing that came up in the f2f today (and apologies in advance for bike-shedding): we think "App History" is confusing because it implies this is about the history of apps on a device or similar. It feels like this has scope across the web. We don't have a good alternative suggestion... WebAppHistory?

Very interesting! I hadn't heard this particular name feedback before, but it makes sense. We have our general bikeshedding issue at WICG/navigation-api#83 . See also some of the discussion on the "app" prefix from a web developer perspective at WICG/navigation-api#83 (comment) .

We're concerned about adding a new API that has to do with history which developers will find confusing on top of the existing history API. At the same time it's clear that it's meeting a user need. The example of XHR and Fetch came up in our discussion. In that case, it was clear what we were asking developers to do - migrate to Fetch. Can we do the same with this API?

Yeah, the plan is indeed that we'd like developers and apps to migrate to this new API, leaving window.history (and perhaps even window.location??) in the dust. The exact details are under discussion in WICG/navigation-api#67 .

[torgo]

Ok given all the above we're going to close this issue for now. However please come back to us when this reaches the next stage of work. Thanks!

[domenic]

FYI working with Mozilla and the web developer community we settled on the replacement name "navigation API", with window.navigation as the entrypoint.

The work has also reached its next stage, so I'll open a new review for that!