Intent to Deprecate and Remove: navigateEvent.restoreScroll()
Nate Chapin
Contact emails
jap...@chromium.org, dom...@chromium.org
Explainer
None
Specification
https://github.com/WICG/navigation-api/pull/239
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
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/239
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/webki...@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?
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.
Chris Harrelson
--
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+...@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.
Yoav Weiss
Contact emails
jap...@chromium.org, dom...@chromium.org
Explainer
None
Specification
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
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
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/webki...@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?
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.
Mike Taylor
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAL5BFfV4tOrryOyNx8LFx4RKWSBYrTU4i2OwOR2VTxf%2BdUwr%2Bg%40mail.gmail.com.