LGTM1 - I'm excited about this API, and hopeful we can smooth over the
subtle interop issues that you've documented. But I see this as a huge
ergonomics win over the status quo, and am encouraged by the careful
work y'all have done.
On 4/18/22 11:39 AM, Domenic Denicola wrote:
On Mon, Apr 18, 2022 at 10:49 AM Mike Taylor <[email protected]>
wrote:
On 4/12/22 12:08 PM, Domenic Denicola wrote:
Contact emails
[email protected], [email protected]
Explainer
https://github.com/WICG/navigation-api/blob/main/README.md
<https://github.com/WICG/navigation-api/blob/main/README.md>
(Aside: This explainer is a master-class in writing explainers.
Incredibly well done - I really appreciate the effort that went
into this).
Specification
https://wicg.github.io/navigation-api/
<https://wicg.github.io/navigation-api/>
Summary
The window.navigation API provides the ability to intercept and
initiate navigations, as well as introspect an application's
history entries. This provides a more useful alternative to
window.history and window.location, specifically aimed at the
needs of single-page web applications.
(Note: this API was formerly known as the app history API.)
Blink component
Blink>History
<https://bugs.chromium.org/p/chromium/issues/list?q=component:Blink%3EHistory>
TAG review
https://github.com/w3ctag/design-reviews/issues/605
<https://github.com/w3ctag/design-reviews/issues/605>
https://github.com/w3ctag/design-reviews/issues/717
<https://github.com/w3ctag/design-reviews/issues/717>
TAG review status
Issues addressed
Link to origin trial feedback summary
https://docs.google.com/document/d/1oDtVhNJaDyEAqsthe07wJaGNVpt-g4TLB4A0-lU2lr4/edit?usp=sharing
<https://docs.google.com/document/d/1oDtVhNJaDyEAqsthe07wJaGNVpt-g4TLB4A0-lU2lr4/edit?usp=sharing>
Risks
Interoperability
The biggest interoperability risk with this API is that it is
building on a rocky foundation. The existing session history spec
does not match browsers very well, and browsers do not match each
other. Since this new API layers on top of the existing model,
this could cause issues.
We have attempted to address this via a solid and well-tested
specification for the new API, as well as ongoing efforts in
whatwg/html PR #6315
<https://github.com/whatwg/html/pull/6315>and elsewhere on the
HTML Standard issue tracker
<https://github.com/whatwg/html/issues?q=is%3Aopen+is%3Aissue+label%3A%22topic%3A+navigation%22%2C%22topic%3A+history%22%2C%22topic%3A+browsing+context%22>to
reform the foundational parts of the specification. For example,
although the navigation API's new events, such as
currententrychange, are fired at well-specified times, there is
an existing interop problem
<https://github.com/whatwg/html/issues/1792>regarding the timing
of popstate vs. hashchange events, which makes it difficult to
write tests for the ordering of currententrychange vs.
hashchange/popstate. Working on such existing interop issues and
specification problems, and then expanding the navigation API
test suite to cover any such interactions, is our team's top
priority after this launch. See also this tracking issue
<https://github.com/WICG/navigation-api/issues/221>.
I do have slight concerns
<https://github.com/whatwg/html/issues/1792#issuecomment-1101459682>
over the popstate/hashchange event change - I fear that might
result in more back button traps for Chromium users (that sadly
Gecko users experience today). But I could be wrong - do you have
any plans to measure and monitor abuse? Or do we have existing
metrics?
To make sure we are on the same page: at this point we are discussing
a future Intent to Ship about a separate behavior change, and we are
not discussing the Navigation API.
Correct - and to be extra clear, any potential future I2S is not
influencing this I2S in my mind.
Our plan for that future Intent to Ship does indeed involve careful
monitoring. However I don't think it has any chance of increasing
back-trapping. Deterministically firing the events in the order (sync
popstate, async hashchange) like Gecko does, instead of Chrome's
version where sometimes it's (async popstate, async hashchange) and
sometimes it's (async hashchange, async popstate) depending on network
conditions and page size, should not increase back-trapping.
OK, I'm very happy to be wrong here. :)
Regarding whether this new API will be implemented in other
browsers, we have been encouraged by the consistent and positive
collaboration with Gecko engineers, which has led to several API
changes and a good amount of review. (We have no signal from WebKit.)
Compatibility
This has been the team's main focus for the last few months, as
we burned through the list of potentially-compat-impacting issues
<https://github.com/WICG/navigation-api/milestone/1>. In
collaboration with Gecko this led to several improvements, such
as the API rename (from app history), a change
<https://github.com/WICG/navigation-api/issues/111>in how
replacement navigations are requested, and the addition
<https://github.com/WICG/navigation-api/issues/76>of an indicator
for when a download is requested. We believe the remaining issues
(3 at the time of writing) are manageable:
*
#72 <https://github.com/WICG/navigation-api/issues/72>: this
will result in firing an event more often during extreme edge
case scenarios involving replacement navigations, or in
less-rare-but-still-rare scenarios involving the user
clearing their history. Neither case should prove problematic.
*
#207 <https://github.com/WICG/navigation-api/issues/207>: the
most likely solution will either be leaving things as they
are, or changing the timing of an event in a way that will
not disturb "normal" usage of the API. Although such a timing
change could be risky if this API had wide deployment, we
believe that changing the timing within a milestone or three
would not be problematic if it ends up being desirable.
*
#202 <https://github.com/WICG/navigation-api/issues/202>:
this issue is about the default for how focus is managed
following a navigation API-intercepted navigation. We believe
the currently-chosen default is probably the best, especially
given testaments on that thread from the accessibility
community and from web framework authors. However we have not
yet closed the issue as we haven't concluded the discussion
with Gecko engineers. Similar to #207, this would probably be
changeable within a few milestones if necessary, without
significant impact to sites using the API. And if we did
change it, early-adopter sites could easily restore the
previous behavior by changing the value of an option.
I agree that these issues seem tractable in the near-term.
Signals
Gecko: No signal
<https://github.com/mozilla/standards-positions/issues/543>.
Initial positive opinions on the issue, and continued engagement
on the design, but not yet an official position.
WebKit: No signal
<https://lists.webkit.org/pipermail/webkit-dev/2021-September/031987.html>.
Web developers: Strongly positive
<https://github.com/WICG/proposals/issues/20>. The initial public
proposal, as well as the issue tracker and Twitter, has had great
engagement and enthusiasm from developers. Origin trial feedback
was also encouraging. In addition, we have several conversations
going on with frameworks, libraries, and larger websites to
ensure that we're solving the problems they see with today's
history API. So far reactions have been either positive, or
requesting that we add additional functionality (most notably #32
<https://github.com/WICG/app-history/issues/32>).
Ergonomics
Although this API layers onto the same underlying model as
window.history, and will have well-specified interactions with
it, the exact integrations may be confusing. (For example,
navigation.navigate() will behave differently from
history.pushState().) We've done our best to smooth over these
rough edges where possible, but have favored making the
navigation API pleasant to use over making it perfectly align
with window.history.
Activation
This feature is hard to polyfill, but developers have managed to
produce something that works in many cases: frehner/appHistory
<https://github.com/frehner/appHistory>is one, and
virtualstate/navigation
<https://github.com/virtualstate/navigation>another.
We've also seen a pattern where developers have existing
history/navigation wrappers (e.g. router libraries or
app-specific history and navigation code) which they can adapt
with a new navigation API-based backend for browsers that support it.
Security
We believe the security risks of this feature are minimal because
of how it is scoped to same-origin contiguous history entries,
and similarly only allows interception of same-origin
navigations. We also need to ensure that we don't allow
"trapping" the user by preventing them from using their back
button; the API is designed to prevent this.
See the specification's security and privacy discussion
<https://wicg.github.io/navigation-api/#security-privacy>for more.
WebView Application Risks
Does this intent deprecate or change behavior of existing APIs,
such that it has potentially high risk for Android WebView-based
applications?
This feature does not introduce any changes to existing APIs.
Debuggability
This feature mostly has no need for extended tooling.
crbug.com/1252940
<https://bugs.chromium.org/p/chromium/issues/detail?id=1252940>tracked
adding the newly-introduced events to the Event Listener
Breakpoints panel.
Is this feature fully tested by web-platform-tests
<https://chromium.googlesource.com/chromium/src/+/master/docs/testing/web_platform_tests.md>?
Yes
<https://wpt.fyi/results/navigation-api?label=master&label=experimental&aligned>.
These results show a strange number of failures for Chromium. We
suspect this is due to the test runner on wpt.fyi, as running the
tests locally, or in a live Chrome browser, does not exhibit the
issue. See web-platform-tests/wpt#33590
<https://github.com/web-platform-tests/wpt/issues/33590>.
Flag name
NavigationApi
Requires code in //chrome?
False
Tracking bug
https://bugs.chromium.org/p/chromium/issues/detail?id=1183545
<https://bugs.chromium.org/p/chromium/issues/detail?id=1183545>
Launch bug
https://bugs.chromium.org/p/chromium/issues/detail?id=1252954
<https://bugs.chromium.org/p/chromium/issues/detail?id=1252954>
Measurement
https://chromestatus.com/metrics/feature/timeline/popularity/4056
<https://chromestatus.com/metrics/feature/timeline/popularity/4056>
Non-OSS dependencies
Does the feature depend on any code or APIs outside the Chromium
open source repository and its open-source dependencies to function?
No.
Sample links
https://gigantic-honored-octagon.glitch.me/
<https://gigantic-honored-octagon.glitch.me/>
https://selective-heliotrope-dumpling.glitch.me/
<https://selective-heliotrope-dumpling.glitch.me/>
Estimated milestones
We plan to land this API in M102.
Link to entry on the Chrome Platform Status
https://chromestatus.com/feature/6232287446302720
<https://chromestatus.com/feature/6232287446302720>
Links to previous Intent discussions
Intent to Prototype
<https://groups.google.com/a/chromium.org/g/blink-dev/c/R1D5xYccqb0/m/8ukfzdVSAgAJ>
Intent to Experiment
<https://groups.google.com/a/chromium.org/g/blink-dev/c/ki__L-IiR0Q/m/rG3OgSkKBQAJ>
This intent message was generated by Chrome Platform Status
<https://chromestatus.com/>and then cleaned up a good bit.
--
You received this message because you are subscribed to the
Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it,
send an email to [email protected].
To view this discussion on the web visit
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAM0wra8BD%2Bea9fSiRGyPJeAZ2KknQe6c9Xmza5BS7O94ktjXiA%40mail.gmail.com
<https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAM0wra8BD%2Bea9fSiRGyPJeAZ2KknQe6c9Xmza5BS7O94ktjXiA%40mail.gmail.com?utm_medium=email&utm_source=footer>.
--
You received this message because you are subscribed to the Google Groups
"blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To view this discussion on the web visit
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/1b595bfd-f0a6-9acb-0f86-98274627fe82%40chromium.org.
