Navigation Activation Info

[noamr]

こんにちは TAG-さん!

I'm requesting a TAG review of Navigation Activation Info.

This is a small addition to the navigation API, that exposes information about the last cross-document navigation.

• Explainer¹ (minimally containing user needs and example code): https://github.com/WICG/view-transitions/blob/main/navigation-activation-explainer.md

• Specification URL: https://html.spec.whatwg.org/multipage/nav-history-apis.html#navigation-activation-interface

• Tests: https://wpt.fyi/results/navigation-api/navigation-activation?label=master&label=experimental&aligned

• User research: TBD

• Security and Privacy self-review²: https://github.com/WICG/view-transitions/blob/main/nav-activation-security-privacy-review.md

• GitHub repo (if you prefer feedback filed there): N/A

• Primary contacts (and their relationship to the specification):

  • [Noam Rosenthal] (@noamr), Google
  • [Khushal Sagar] (@khushalsagar), Google
  • [Vladimir Levin] (@vmpstr), Google
  • [Nate Chapin] (@natechapin), Google
  • [Domenic Denicola] (@domenic), Google

• Organization(s)/project(s) driving the specification: Google

• Key pieces of existing multi-stakeholder review or discussion of this specification: Mozilla standards position, Spec issue, Spec PR

• External status/issue trackers for this specification (publicly visible, e.g. Chrome Status): https://chromestatus.com/feature/5076557983121408

Further details:

• I have reviewed the TAG's Web Platform Design Principles
• Relevant time constraints or deadlines: [please provide]
• The group where the work on this specification is currently being done: WHATWG
• The group where standardization of this work is intended to be done (if current group is a community group or other incubation venue): WHATWG
• Major unresolved issues with or opposition to this specification: None at the moment.
• This work is being funded by: Google

You should also know that this is implemented in Chromium behind a flag.

[please tell us anything you think is relevant to this review]

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

☂️ open a single issue in our GitHub repo for the entire review

💬 leave review feedback as a comment in this issue and @-notify [github usernames]

---

CAREFULLY READ AND DELETE CONTENT BELOW THIS LINE BEFORE SUBMITTING

Please preview the issue and check that the links work before submitting.

In particular, if anything links to a URL which requires authentication (e.g. Google document), please make sure anyone with the link can access the document. We would prefer fully public documents though, since we work in the open.

¹ We require an explainer to give the relevant context for the spec review, even if the spec has some background information. For background, see our explanation of how to write a good explainer. We recommend the explainer to be in Markdown.

² A Security and Privacy questionnaire helps us understand potential security and privacy issues and mitigations for your design, and can save us asking redundant questions. See https://www.w3.org/TR/security-privacy-questionnaire/.

[torgo]

Hi @noamr - thanks for sending this our way.

A couple of initial questions we had after reviewing in today's TAG breakout:

1. regarding the naming of the API - it seems like the term "Activation" is a bit overloaded - in particular it's used in the context of user activation which is a completely separate concept. We're concerned this could cause developer confusion. Have you considered any alternatives?

2. what's the current state of this with regard to the HTML spec itself?

3. the security & privacy responses say that "It exposes information about the most recent cross-document navigation." It's not clear if this means it's exposing additional information that the developer wouldn't have had access to before or if it's information that the developer would have had access to anyway? In general there is a lack of information in the explainer about potential abuse cases. It's concerning that this is exposing information about navigation across documents as this could be a potential privacy issue... so I think some additional discussion of this is warranted in the explainer.

4. do you have any information about multi-implementer support?

[noamr]

Hi @noamr - thanks for sending this our way.

A couple of initial questions we had after reviewing in today's TAG breakout:

1. regarding the naming of the API - it seems like the term "Activation" is a bit overloaded - in particular it's used in the context of user activation which is a completely separate concept. We're concerned this could cause developer confusion. Have you considered any alternatives?

Yes, we've considered many alternatives.
"Activation" is already used in prerendering, e.g. the "activationStart" is when the actual navigation to the prerendered page occurs. Note that you wouldn't use the term activation on its own here, it's always navigation.activation. A navigation activation feels distinct enough from user-activation.

2. what's the current state of this with regard to the HTML spec itself?

This is integrated into the HTML spec. https://html.spec.whatwg.org/multipage/nav-history-apis.html#navigation-activation-interface

3. the security & privacy responses say that "It exposes information about the most recent cross-document navigation." It's not clear if this means it's exposing additional information that the developer wouldn't have had access to before or if it's information that the developer would have had access to anyway? In general there is a lack of information in the explainer about potential abuse cases. It's concerning that this is exposing information about navigation across documents as this could be a potential privacy issue... so I think some additional discussion of this is warranted in the explainer.

Fair point I'll add it to the explainer. This exposes only information that's available otherwise but requires a lot of broiler-plate JS with sessionStorage or service-workers to implement reliably.

4. do you have any information about multi-implementer support?

Mozilla supports: mozilla/standards-positions#928
No signal from WebKit: WebKit/standards-positions#282

[torgo]

Hi @noamr thanks for your response. We're still slightly concerned about the name collision but we get what you mean about always referring it to as "navigation activation." We'd like to encourage you to do more when it comes to documenting potential abuse cases and mitigations in both the explainer and the spec. It's good to see some multi-implementer support. We're happy to see this proceed.

[noamr]

Hi @noamr thanks for your response. We're still slightly concerned about the name collision but we get what you mean about always referring it to as "navigation activation." We'd like to encourage you to do more when it comes to documenting potential abuse cases and mitigations in both the explainer and the spec. It's good to see some multi-implementer support. We're happy to see this proceed.

Thanks for the review, I updated the explainer with a priv&sec section as requested.
https://github.com/WICG/view-transitions/blob/main/navigation-activation-explainer.md

[nickcoury]

This would be a greatly welcome addition. I prototyped an MPA VT experience a couple months ago and this was the biggest blocker to it working. I tried several versions of saving navigation timestamps in history and/or navigation state entries on page load, and looking up the most recent previous page to determine the index and direction. It was unreliable. From my notes, sometimes the timestamps saved to entries forward in the navigation stack would disappear. I'm not sure if this was a browser bug or internal logic from another team, as I was building it into a large production app. Regardless, it can be buggy and unreliable to depend on this approach whereas the browser always knows the truth.

My animation was an iOS-style slide of the new page in/out, and sometimes a back navigation would play the forward slide which would be extremely disorienting for users.

If I recall, it was also slightly painful to coordinate across full page loads and bfcache navigations.

At minimum, I'd want to have the size and direction of the jump, e.g. -1 for back, 0 for refresh, 1 for forward, larger numbers for multi-jumps. This is easy enough with the explainer proposal. It might be useful to have convenience fields for jumpSize, isBack, etc. if it is acceptable to increase API size. Otherwise developers will all implement similar boilerplate e.g. https://twitter.com/matthewcp/status/1734947279167955253