Intent to Deprecate and Remove: navigateEvent.restoreScroll()

73 views
Skip to first unread message

Nate Chapin

unread,
Jul 18, 2022, 8:06:28 PM7/18/22
to blink-dev

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

Blink>History


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

unread,
Jul 18, 2022, 11:05:28 PM7/18/22
to Nate Chapin, blink-dev
LGTM1

--
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

unread,
Jul 19, 2022, 9:10:16 AM7/19/22
to Nate Chapin, blink-dev
LGTM2

On Tue, Jul 19, 2022 at 2:06 AM Nate Chapin <jap...@chromium.org> wrote:

Contact emails

jap...@chromium.org, dom...@chromium.org


Explainer

None


I think that a short (even inline) explainer can be useful to explain what scroll does differently than restoreScroll and how developers would use it. The PR's explanation (once I actually found it) is a good one.
 

This seems like the right PR, but the link is pointing at the wrong one. It should be 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

Blink>History


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


Same here. Wrong link.. Should be 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.)


Usage seems low enough and we're close enough to when we shipped this that changing course now seems reasonable.
  

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

unread,
Jul 19, 2022, 9:34:54 AM7/19/22
to Yoav Weiss, Nate Chapin, blink-dev
Reply all
Reply to author
Forward
0 new messages