Add a navigation counter to Documents

[clelland]

• At least two implementers are interested (and none opposed):
  • Chrome
  • …
• Tests are written and can be reviewed and commented upon at:
  • This is not tested directly, as the counter is not directly web-exposed. However, it enables the tests for a number of performance APIs:
    • performance-timeline/back-forward-cache-restoration.tentative.html
    • performance-timeline/navigation-id-detached-frame.tentative.html
    • performance-timeline/navigation-id-long-task-task-attribution.tentative.html
    • performance-timeline/navigation-id-mark-measure.tentative.html
    • performance-timeline/navigation-id-element-timing.tentative.html
    • performance-timeline/navigation-id-resource-timing.tentative.html
    • performance-timeline/navigation-id-initial-load.tentative.html
    • performance-timeline/navigation-id-reset.tentative.html
• Implementation bugs are filed:
  • Chrome: 1273925
  • Firefox: 1809226
  • Safari: 250331

(See WHATWG Working Mode: Changes for more details.)

---

/browsing-the-web.html ( diff )

---

/browsing-the-web.html ( diff )

[clelland]

This is prerequisite work for w3c/performance-timeline#192 - tests and bugs are incoming; I'll update the description as those are completed.

[annevk]

This seems more like a bfcache counter? It would help to have a little more context for review.

[clelland]

The idea is that there are several ways that a user can do something that is perceived as a 'navigation' that will not actually reset any state in the document. Currently, I can think of:

• initial page load
• restoration from session history (bfcache)
• App history (SPA) navigation

There might be more, but these at least would increment this counter. The counter itself would be exposed in PerformanceEntry objects in the Performance Timeline. This allows consumers of that timeline to segment performance events by user navigation, and to understand the performance of the page in that context.

See w3c/performance-timeline#182 for more context, and w3c/performance-timeline#192 for the actual proposed integration there.

[annevk]

We should probably note that this can be a (limited) tracking vector and that it ought to be cleared when the user clears website data. (It's not entirely clear to me that would logically follow from bfcache or app history requirements, although it prolly should.)

[domenic]

Currently, I can think of:

I'm wondering why an app history navigation is treated specifically here, as opposed to a pushState() or replaceState(). The difference between the two is app history navigations have a clear duration, and an additional (async) success or failure signal. But IMO both should be counted as "navigations", and that is what https://github.com/WICG/app-history/#performance-timeline-api-integration envisions.

[domenic]

Alternately if the intent is really more of "how many times has pageshow been called", then I would change this to "pageshow counter" and change the corresponding performance API from navigationId to pageshowCounter or similar.

[clelland]

I'm wondering why an app history navigation is treated specifically here, as opposed to a pushState() or replaceState()

pushState and replaceState and friends aren't a clear signal that the user would have perceived something like a navigation -- they are often used that way, but they're just as often used to update the address bar without any real 'transition' taking place. That's why we have the AppHistory API, and I think that we only want to count the declarative use of appHistory.navigate.

Alternately if the intent is really more of "how many times has pageshow been called"

Is pageshow fired on app history navigations? If so, thats' a possibility.

[domenic]

I think that's unfortunately based on a misunderstanding of the app history API. As I said, the only distinction between the two is a duration and async success/failure signal.

There's nothing special about navigations from appHistory.navigate(); appHistory.navigate() is just location.assign() with a few more options. You can override the behavior of location.assign() or appHistory.navigate() or history.pushState() using the navigate event listener to be a duration-having SPA nav. But doing so is agnostic to the source of navigation.

I think the only principled distinction you can make is between cross-document navigations and same-document navigations. Making a distinction based on what API people use is not something the current app history spec infrastructure supports, nor is it something I recommend.

Is pageshow fired on app history navigations? If so, thats' a possibility.

No.

[clelland]

My understanding of the AppHistory API is that it can do two things for us here:

1. It exposes a difference between script-initiated and user-initiated history state transitions
2. It provides a new way to declare that a navigation transition has completed (with the resolution of the .navigate promise)

My goal is to capture, or rather to allow interested developers to capture the idea of user-visible navigation-like transitions, to be able to use that to reason about page performance. In some cases, these transitions are full-document reloads, in others they are bfcache restorations (which may be indistinguishable to the user from the first case, but don't change any document state), and in other cases, they are SPA navs (which don't load a different document, but may change significant page state).

Since there are a large number of sites which use the existing history API to record page state information without what the user would see as a 'navigation', I don't know if we can tie this counter to that API. However, the fact that the AppHistory API provides an explicit navigation signal (especially with the 'user-initiated' concept,) it seems that we could leverage that to give developers the option to have those marked as 'navigations' in the performance timeline, by hooking those events up to this counter.

Should this discussion be moved to https://github.com/WICG/app-history/issues?

[domenic]

Right, I'm saying this is not a correct impression. userInitiated applies to all navigations causes by clicking on links or submitting forms, and to zero navigations caused by navigate(). And all navigations can have duration once you use app history, including pushState() ones.

I'm OK with any venue for discussion.

[clelland]

Coming back to this: Tying to the Navigation API, as @domenic says, is probably not possible.

I'm fine with any naming that folks think make sense.

The intention is to collect "user-perceived" navigation transitions. Updates to state which are effectively the same to a user as a back or forward navigation, but which don't actually create a new browsing context, should update this member.

Initially, this should tie into back-forward-cache restorations, and Chrome would like to use this to expose SPA transitions through https://bit.ly/soft-navigation heuristics, hence the more inclusive proposed name.

[domenic]

I still find the current state, and eventual desired end state, confusing. I re-read the two threads you linked above but between them I think I see about 4 possible proposals floating around. Is there an explainer available?

[clelland]

I've written up a short motivation, and the concrete proposal, here: https://github.com/clelland/navigationId

[annevk]

Where is the concrete proposal? I'm afraid that "An SPA navigation is detected" isn't something that makes normative sense.

[clelland]

@yoavweiss is working on a way to specify that precisely; the latest work is at https://github.com/yoavweiss/soft-navigations/, which is now linked.

The heuristics there would be used to trigger a new SoftNavigation performance entry in the performance timeline. Like a back-forward cache restoration, this SPA navigation would update the navigationId to a new value, and include that value in the SoftNavigation entry in the timeline. Subsequent timeline events, up until the next cache restoration or SPA nav, would reference that new navigationId.

[domenic]

This design seems reasonable to me. I wish it didn't use the phrase "navigation ID", since we're already using that for a spec-level concept that identifies actual navigations in the sense of the navigate <dfn>. But I don't have any better ideas, and web developers have priority.

[clelland]

I think that this can be done differently, entirely within the Performance Timeline API with less intrusion into HTML's navigation algorithms. I've updated w3c/performance-timeline#192, and I'll close this for now.