Repository navigation
Add the navigation API - #8502
Conversation
99f4e40 to
4dbf993
Compare
68f4303 to
836044a
Compare
This imports much of the specification from https://wicg.github.io/navigation-api/. It includes some minor fixes and renamings, as well as a lot of rearranging to flow better, but the feature set is the same.
836044a to
fe5bbc4
Compare
Aligns with latest work in https://chromium-review.googlesource.com/c/chromium/src/+/4262131/10
The specification work has moved to whatwg/html#8502. The TypeScript definitions have moved to DefinitelyTyped: https://github.com/DefinitelyTyped/DefinitelyTyped/blob/master/types/dom-navigation/index.d.ts.
The specification work has moved to whatwg/html#8502. The TypeScript definitions have moved to DefinitelyTyped: https://github.com/DefinitelyTyped/DefinitelyTyped/blob/master/types/dom-navigation/index.d.ts.
The specification work has moved to whatwg/html#8502. The TypeScript definitions have moved to DefinitelyTyped: https://github.com/DefinitelyTyped/DefinitelyTyped/blob/master/types/dom-navigation/index.d.ts.
Found while doing a code refactoring in https://chromium-review.googlesource.com/c/chromium/src/+/4369772 #2621 is related, but since we don't have an overall fix yet, let's patch it here
| document">focused area</span> to <var>document</var>'s <span>viewport</span>, and set | ||
| <var>document</var>'s <span>relevant global object</span>'s <span | ||
| data-x="window-navigation-api">navigation API</span>'s <span>focus changed during ongoing | ||
| navigation</span> to false.</p> |
There was a problem hiding this comment.
This is surprising. Why would removing a node clear such flag.
There was a problem hiding this comment.
So how focusReset: "after-transition" is supposed to work is as follows:
- If nothing relevant changes in the document, focus gets reset after the transition
- If the user (or developer, but the user is more important) changes focus during the transition, we don't reset the focus: that would be too disruptive.
- But, if the user or developer changes focus during the transition, and then the developer removes the currently-focused DOM node from the document, we do reset the focus.
Without this step you're commenting on, (3) will be missing.
Note here "reset the focus" means the slightly-special behavior in https://whatpr.org/html/8502/nav-history-apis.html#potentially-reset-the-focus , of using the autofocus behavior and also resetting the sequential focus navigation starting point. So it's more than just the focus fixup steps.
What do you think?
| <dt><dfn export data-x="history-action activation-consuming API" data-lt="history-action activation-consuming API">History-action activation-consuming APIs</dfn></dt> | ||
| <dd><p>These APIs require the <span>history-action activation</span> state to be true, and they | ||
| <span>consume history-action user activation</span> in each call to prevent multiple calls per | ||
| user activation.</p></dd> |
There was a problem hiding this comment.
It is unclear why this is needed. (but I'm still reading all this, so perhaps something somewhere clarifies the issue this is trying to solve.)
There was a problem hiding this comment.
This is added to prevent back-trapping. See "traversals have special restrictions on canceling the navigation" in https://github.com/wicg/navigation-api#restrictions-on-firing-canceling-and-responding . It is also envisioned to be used by https://github.com/WICG/close-watcher .
| return true.</p></li> | ||
|
|
||
| <li><p>If <var>document</var>'s <span data-x="concept-document-origin">origin</span> is <span | ||
| data-x="concept-origin-opaque">opaque</span>, then return true.</p></li> |
There was a problem hiding this comment.
This looks surprising. One couldn't use the API for top level opaque documents for example.
There was a problem hiding this comment.
Yes. We haven't run into people using top-level opaque documents who complained, but it's something we could loosen up in the future if you are in contact with some developers who would like to use this API, and can't.
| <li><p>If <var>navigation</var>'s <span>upcoming traverse API method | ||
| trackers</span>[<var>key</var>] <span data-x="map exists">exists</span>, then return a | ||
| <span>navigation API method tracker-derived result</span> for <var>navigation</var>'s | ||
| <span>upcoming traverse API method trackers</span>[<var>key</var>].</p></li> |
There was a problem hiding this comment.
Isn't this surpising? if the key is already there, reuse that even if the map might have gotten other entries after the key was added.
There was a problem hiding this comment.
I don't understand your second sentence, or what's surprising about this behavior. Could you say more?
To be clear, this is about cases like:
const key = navigation.entries()[navigation.currentEntry.index - 1];
const result1 = navigation.traverseTo(key);
// ... probably in some other part of the app ...
const result2 = navigation.traverseTo(key);and says that result2 should just reflect what's going on with result1 (i.e. have the same promises). I'm not sure what other behavior you'd envision here...
Closes #254. This is already reflected in the specification at whatwg/html#8502.
Mozilla is positive. |
|
Thanks so much Simon! Given that we've gotten review on this from multiple sources already, and all the checkboxes in the OP are filled out, I'll plan to merge this Monday (Japan time). Of course, if more reviews come in, I'm happy to delay. |
This imports much of the specification from https://github.com/WICG/navigation-api/blob/91c2e7f959418d71e26e5b9a6723fed2944001d9/spec.bs. It includes some fixes and renamings, as well as a lot of rearranging to flow better, but the feature set is the same.
In addition to the new "navigation API" section under "APIs related to navigation and session history", this makes the following changes to integrate the navigation API:
Introduces the NavigationHistoryBehavior enum, as a superset of the "history handling" specification type. This includes an "auto" value to reflect that existing entry points will sometimes default to "replace" instead of "push". The navigation API allows overriding that auto behavior in some circumstances by explicitly supplying "push". (But in some cases, i.e., the initial
about:blankorjavascript:URLs, this is still not allowed.)Introduces the concept of "user navigation involvement". This will be helpful for solving issues such as Sec-Fetch-User and Sec-Fetch-Site for user-initiated UI navigations w3c/webappsec-fetch-metadata#71.
Introduces the concept of "history-action user activation", which is a separate type of user activation meant to be used specifically to prevent back button tracking. It has no associated timeout (unlike transient activation), but can be flipped to false (unlike sticky activation). It is used by the navigation API to prevent calling
navigateEvent.preventDefault()on two traversals in a row without intervening user activation. It is likely also to be useful for issues such as Specify back button history-entry skipping? #7832.The activation behavior for
<a>and<area>elements is made more rigorous and consolidated into one place, so that we can hook into it appropriately to firenavigateevents.Some surgery was needed on "apply the history step". The result is that it now has slightly more parameters, but also several wrapper algorithms which take care of setting up those parameters correctly for the cases of: navigable creation/destruction, push/replace, reload, and traverse. It also returns a value indicating if the application of the history step was canceled, and if so, how; this is used to give informative errors as return values of
navigation.traverseTo().The "check if unloading is user-canceled" algorithm has become "check if unloading is canceled", as it now handles firing a possibly-cancelable
navigateevent at the top-level traversable.Other changes scattered throughout are mostly integrating appropriate calls to the navigation API as necessary, especially to fire
navigateevents.(See WHATWG Working Mode: Changes for more details.)
/acknowledgements.html ( diff )
/browsing-the-web.html ( diff )
/document-lifecycle.html ( diff )
/document-sequences.html ( diff )
/form-control-infrastructure.html ( diff )
/form-elements.html ( diff )
/forms.html ( diff )
/iframe-embed-object.html ( diff )
/image-maps.html ( diff )
/index.html ( diff )
/indices.html ( diff )
/infrastructure.html ( diff )
/input.html ( diff )
/interaction.html ( diff )
/links.html ( diff )
/nav-history-apis.html ( diff )
/parsing.html ( diff )
/popover.html ( diff )
/semantics.html ( diff )
/server-sent-events.html ( diff )
/text-level-semantics.html ( diff )
/webappapis.html ( diff )