Contact emails jap...@chromium.org, dome...@chromium.org
Explainer None Specification https://github.com/WICG/navigation-api/pull/23 <https://github.com/WICG/navigation-api/pull/235>9 Summary restoreScroll() is being replaced by navigateEvent.scroll(). scroll() works identically except that it allows the developer to control scroll timing for non-traverse navigations (i.e., scroll() works when the scroll is not a restore, hence the name change along with the behavior change). Blink component Blink>History <https://bugs.chromium.org/p/chromium/issues/list?q=component:Blink%3EHistory> Motivation We want to support developer-controlled timing of a navigation-associated scroll in non-traverse cases (e.g., scrolling to a fragment). It makes sense to have the same method drive navigation-related scrolling in both traverse and non-traverse cases, but the name "restoreScroll" is nonsense for push/replace navigations. Initial public proposal https://github.com/WICG/navigation-api/pull/23 <https://github.com/WICG/navigation-api/pull/235>9 TAG review https://github.com/w3ctag/design-reviews/issues/717 TAG review status Issues open Risks Interoperability and Compatibility scroll(), which we plan to ship in the same milestone as this deprecation, is in development and works identically in all cases that restoreScroll() can be used. Also, restoreScroll() only recently shipped (M102). There are few consumers of the API, and we are in contact with most of them already, so we believe we can guide them on any migration challenges they might have. The overall use counter for the navigation API ( https://chromestatus.com/metrics/feature/timeline/popularity/4056) shows 0.000301% of pages on the web using any portion of the API, which provides an upper bound on the potential breakage here. (That use counter also counts various other entry points to the API, which are not being changed.) We plan to support both scroll() and restoreScroll() for 3 releases to provide a migration period (adding scroll() in M105, removing restoreScroll() in M108). We are bundling this change with a similar migration from navigateEvent.transitionWhile() to navigateEvent.intercept() on the same timeline to minimize the developer pain. Gecko: No signal https://github.com/mozilla/standards-positions/issues/543 remains open as the positions request for the original API. WebKit: No signal https://www.mail-archive.com/webkit-dev@lists.webkit.org/msg30257.html remains open as the positions request for the original API. https://github.com/WebKit/standards-positions/issues/34 was recently opened by web developers and also remains open. Web developers: Positive https://github.com/WICG/navigation-api/issues/237 came out of discussions with web developers. Other signals: 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? The deprecation risk here is not especially high for WebView applications. Debuggability N/A Is this feature fully tested by web-platform-tests <https://chromium.googlesource.com/chromium/src/+/main/docs/testing/web_platform_tests.md> ? Official web platform tests support will switch over to scroll() when it lands. We will retain restoreScroll() tests in wpt_internal/navigation-api/ until restoreScroll() is removed. Requires code in //chrome? False Tracking bug https://bugs.chromium.org/p/chromium/issues/detail?id=1345507 Estimated milestones Deprecate: M105. Remove: M108. Link to entry on the Chrome Platform Status https://chromestatus.com/feature/5029730789621760 This intent message was generated by Chrome Platform Status <https://chromestatus.com/>. -- 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 blink-dev+unsubscr...@chromium.org. To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CACf%3D2L%2BJqMivnC8NVq2kAKpd%3DxVUbbh6ySZF-AXvgtMwOK7seg%40mail.gmail.com.
