Intent to Deprecate and Remote: navigateEvent.transitionWhile()

133 views
Skip to first unread message

Nate Chapin

unread,
Jun 14, 2022, 2:25:39 PM6/14/22
to blink-dev

Contact emails

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


Specification

https://github.com/WICG/navigation-api/pull/235


Summary

transitionWhile() is being replaced by navigateEvent.intercept() due to design flaws reported by developers.


The flaws in transitionWhile() were discussed in https://github.com/WICG/navigation-api/issues/230,

the spec update to replace transitionWhile() with intercept() is at https://github.com/WICG/navigation-api/pull/235, and the introduction of intercept() has its own chromestatus entry at https://chromestatus.com/feature/5194055716700160.



Blink component

Blink>History


Motivation

transitionWhile() has design issues that have meant developers have found it difficult to use effectively, detailed in https://github.com/WICG/navigation-api/issues/230#issuecomment-1137891972


intercept() is being introduced to provide a more usable API for the same basic functionality of transitionWhile().



Initial public proposal

https://github.com/WICG/navigation-api/pull/235


TAG review

https://github.com/w3ctag/design-reviews/issues/717


TAG review status

Issues open


Risks



Interoperability and Compatibility

For those migrating to intercept(), the main risk is that web developer "handling" logic will run at a subtly different time, but per the explainer that time will actually be less buggy in the usual case.


Also, transitionWhile() 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.000097% 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 intercept() and transitionWhile() for 3 releases to provide a migration period (adding intercept() in M105, removing transitionWhile() in M108).



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.


Web developers: Positive The problem this was solving was discovered by a web developer in https://github.com/WICG/navigation-api/issues/230, and has some engagement there.


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?



Debuggability

N/A



Is this feature fully tested by web-platform-tests?

No



Requires code in //chrome?

False


Tracking bug

https://bugs.chromium.org/p/chromium/issues/detail?id=1336000


Estimated milestones

Deprecate: M105. Remove: M108.



Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/5169970311856128


This intent message was generated by Chrome Platform Status.


Chris Harrelson

unread,
Jun 22, 2022, 12:24:30 PM6/22/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%3D2LJ2ErzDF1O8eo2BrsW3y9MWQ3XbcFQGJov%3Dcd5q7%3DPgCw%40mail.gmail.com.

Mike Taylor

unread,
Jun 22, 2022, 12:57:50 PM6/22/22
to Chris Harrelson, Nate Chapin, blink-dev
LGTM2

Mike West

unread,
Jun 29, 2022, 10:47:58 AM6/29/22
to Mike Taylor, Chris Harrelson, Nate Chapin, blink-dev
LGTM3.

-mike


To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/172226f9-782e-8786-b3b8-8a3229f5fcc6%40chromium.org.

Domenic Denicola

unread,
Feb 26, 2025, 2:16:13 AMFeb 26
to blink-dev, Mike West, Chris Harrelson, Nate Chapin, blink-dev, Mike Taylor
Hi all,

I randomly discovered today that we forgot to remove one property as part of this deprecation and removal. We successfully removed NavigateEvent's transitionWhile() (replaced with intercept()), but did not remove the property canTransition (replaced with canIntercept).

The percentage of page loads using the navigation API has certainly grown since this Intent was sent (now between 0.1-0.2%). However, I'm hopeful nobody is using canTransition. It's not documented anywhere, whereas canIntercept is. I did some GitHub code searches (e.canTransition, event.canTransition, and a much-noisier canTransition) and didn't find anything that would break: there was one case where it was being logged informationally, and a couple other cases where it was being used alongside transitionWhile(). Since transitionWhile() does not exist anymore, such code is already broken and thus likely not being used in the wild.

Which path of action would the API owners prefer?
  • Immediately disable canTransition, with a Finch flag to reenable it if that breaks something, based on the approval of this intent.
  • Add use counters and UKM, and wait for them to reach stable. Then, assuming all looks good, send a second Intent to Remove.

LGTM1

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.
--
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+unsubscribe@chromium.org.

--
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+unsubscribe@chromium.org.

Chris Harrelson

unread,
Feb 26, 2025, 11:32:33 AMFeb 26
to Domenic Denicola, blink-dev, Mike West, Nate Chapin, Mike Taylor
On Tue, Feb 25, 2025 at 11:16 PM Domenic Denicola <dom...@chromium.org> wrote:
Hi all,

I randomly discovered today that we forgot to remove one property as part of this deprecation and removal. We successfully removed NavigateEvent's transitionWhile() (replaced with intercept()), but did not remove the property canTransition (replaced with canIntercept).

The percentage of page loads using the navigation API has certainly grown since this Intent was sent (now between 0.1-0.2%). However, I'm hopeful nobody is using canTransition. It's not documented anywhere, whereas canIntercept is. I did some GitHub code searches (e.canTransition, event.canTransition, and a much-noisier canTransition) and didn't find anything that would break: there was one case where it was being logged informationally, and a couple other cases where it was being used alongside transitionWhile(). Since transitionWhile() does not exist anymore, such code is already broken and thus likely not being used in the wild.

Which path of action would the API owners prefer?
  • Immediately disable canTransition, with a Finch flag to reenable it if that breaks something, based on the approval of this intent.

I'm supportive of immediately disabling, to minimize the chance we won't be able to remove it later in case usage increases.
 
LGTM1

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
--
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.

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

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

Vladimir Levin

unread,
Feb 26, 2025, 4:05:36 PMFeb 26
to Chris Harrelson, Domenic Denicola, blink-dev, Mike West, Nate Chapin, Mike Taylor
On Wed, Feb 26, 2025 at 11:32 AM Chris Harrelson <chri...@chromium.org> wrote:


On Tue, Feb 25, 2025 at 11:16 PM Domenic Denicola <dom...@chromium.org> wrote:
Hi all,

I randomly discovered today that we forgot to remove one property as part of this deprecation and removal. We successfully removed NavigateEvent's transitionWhile() (replaced with intercept()), but did not remove the property canTransition (replaced with canIntercept).

The percentage of page loads using the navigation API has certainly grown since this Intent was sent (now between 0.1-0.2%). However, I'm hopeful nobody is using canTransition. It's not documented anywhere, whereas canIntercept is. I did some GitHub code searches (e.canTransition, event.canTransition, and a much-noisier canTransition) and didn't find anything that would break: there was one case where it was being logged informationally, and a couple other cases where it was being used alongside transitionWhile(). Since transitionWhile() does not exist anymore, such code is already broken and thus likely not being used in the wild.

Which path of action would the API owners prefer?
  • Immediately disable canTransition, with a Finch flag to reenable it if that breaks something, based on the approval of this intent.

I'm supportive of immediately disabling, to minimize the chance we won't be able to remove it later in case usage increases.

+1 (with a finch flag)
 

Domenic Denicola

unread,
Feb 26, 2025, 9:24:23 PMFeb 26
to Vladimir Levin, Chris Harrelson, Domenic Denicola, blink-dev, Mike West, Nate Chapin, Mike Taylor
On Thu, Feb 27, 2025 at 6:05 AM Vladimir Levin <vmp...@chromium.org> wrote:


On Wed, Feb 26, 2025 at 11:32 AM Chris Harrelson <chri...@chromium.org> wrote:


On Tue, Feb 25, 2025 at 11:16 PM Domenic Denicola <dom...@chromium.org> wrote:
Hi all,

I randomly discovered today that we forgot to remove one property as part of this deprecation and removal. We successfully removed NavigateEvent's transitionWhile() (replaced with intercept()), but did not remove the property canTransition (replaced with canIntercept).

The percentage of page loads using the navigation API has certainly grown since this Intent was sent (now between 0.1-0.2%). However, I'm hopeful nobody is using canTransition. It's not documented anywhere, whereas canIntercept is. I did some GitHub code searches (e.canTransition, event.canTransition, and a much-noisier canTransition) and didn't find anything that would break: there was one case where it was being logged informationally, and a couple other cases where it was being used alongside transitionWhile(). Since transitionWhile() does not exist anymore, such code is already broken and thus likely not being used in the wild.

Which path of action would the API owners prefer?
  • Immediately disable canTransition, with a Finch flag to reenable it if that breaks something, based on the approval of this intent.

I'm supportive of immediately disabling, to minimize the chance we won't be able to remove it later in case usage increases.

+1 (with a finch flag)

Thanks both for the quick response! We removed it (with a flag) in https://chromium-review.googlesource.com/c/chromium/src/+/6305452 , so it will be gone from M135+.

I will tweak the ChromeStatus entry to include this info, and check with the relevant tech writers to see if they want to mention this in the beta blog post.
Reply all
Reply to author
Forward
0 new messages