Intent to Ship: Sticky user activation across same-origin navigations

197 views
Skip to first unread message

Chromestatus

unread,
Aug 28, 2025, 4:17:22 PM (7 days ago) Aug 28
to blin...@chromium.org, vmp...@chromium.org, mus...@chromium.org

Contact emails

mus...@chromium.org

Explainer

None

Specification

https://github.com/whatwg/html/pull/11454

Summary

This feature preserves the sticky user activation state after a page navigates to another same-origin page. The lack of user activation in the post-navigation page prevents some use cases like showing virtual keyboards on auto-focus, and this has been a blocker for the developers who want to build MPAs over SPAs.



Blink component

Blink>Input

TAG review

None

TAG review status

Pending

Risks



Interoperability and Compatibility

None



Gecko: Positive (https://github.com/WICG/view-transitions/issues/239#issuecomment-2851155373)

WebKit: Positive (https://github.com/whatwg/html/issues/11328#:~:text=anne%3A%20sounds%20good.%20i%20dont%20think%20we%20will%20regret%20this%2C%20but%20we%20will%20have%20to%20test%20it%20carefully)

Web developers: Positive (https://github.com/WICG/view-transitions/issues/239)

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?

None



Debuggability

None



Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, ChromeOS, Android, and Android WebView)?

Yes

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

No

Flag name on about://flags

None

Finch feature name

None

Non-finch justification

None

Rollout plan

Will ship enabled for all users

Requires code in //chrome?

False

Tracking bug

https://issues.chromium.org/433729626

Sample links


https://vmpstr.github.io/htmldemos/activation/a.html

Estimated milestones

Shipping on desktop 142
Shipping on Android 142
Shipping on WebView 142


Anticipated spec changes

Open questions about a feature may be a source of future web compat or interop issues. Please list open issues (e.g. links to known github issues in the project for the feature specification) whose resolution may introduce web compat/interop risk (e.g., changing to naming or structure of the API in a non-backward-compatible way).

None

Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/5078337520926720?gate=5110603664064512

This intent message was generated by Chrome Platform Status.

Daniel Clark

unread,
Aug 28, 2025, 9:45:47 PM (7 days ago) Aug 28
to Chromestatus, blin...@chromium.org, vmp...@chromium.org, mus...@chromium.org
It’d be good to have official standards positions filed or at least to get Gecko and WebKit signoff on the spec PR. I agree from the notes that the sentiment looks positive but statements like “I don’t think we will regret this” are not as firm as I’d like :).

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

Could you add WPTs for this?

> Finch feature name
> None

This would be shipped gated by a flag, right?

-- Dan


--
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 visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/68b0b943.050a0220.270bc4.0090.GAE%40google.com.

Mustaq Ahmed

unread,
Sep 2, 2025, 2:04:54 PM (3 days ago) Sep 2
to Daniel Clark, Chromestatus, blin...@chromium.org, vmp...@chromium.org
On Thu, Aug 28, 2025 at 9:45 PM Daniel Clark <dan...@microsoft.com> wrote:

It’d be good to have official standards positions filed or at least to get Gecko and WebKit signoff on the spec PR. I agree from the notes that the sentiment looks positive but statements like “I don’t think we will regret this” are not as firm as I’d like :).

 The spec PR is currently under review from Gecko.  I would give it some time to settle.

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

Could you add WPTs for this?

I believe in WPT we can't have an a.html top-frame navigate to b.html and check things there.  I was not able to find an example in wpt/navigation-api/.  Did I miss anything?


> Finch feature name
> None
This would be shipped gated by a flag, right?

Thanks for the catch.  I corrected the chromestatus entry to "StickyUserActivationAcrossSameOriginNavigation". 

Daniel Clark

unread,
Sep 2, 2025, 8:04:34 PM (2 days ago) Sep 2
to Mustaq Ahmed, Chromestatus, blin...@chromium.org, vmp...@chromium.org

> I believe in WPT we can't have an a.html top-frame navigate to b.html and check things there.  I was not able to find an example in wpt/navigation-api/.  Did I miss anything?

 

I think it’s correct that we can’t test it with top-level navigations, but can we test it for iframe navigations? The way I understand https://github.com/whatwg/html/pull/11454 iframe navs should also get the new behavior.

Domenic Denicola

unread,
Sep 2, 2025, 8:59:18 PM (2 days ago) Sep 2
to Daniel Clark, Mustaq Ahmed, Chromestatus, blin...@chromium.org, vmp...@chromium.org
On Wed, Sep 3, 2025 at 9:04 AM 'Daniel Clark' via blink-dev <blin...@chromium.org> wrote:

> I believe in WPT we can't have an a.html top-frame navigate to b.html and check things there.  I was not able to find an example in wpt/navigation-api/.  Did I miss anything?

 

I think it’s correct that we can’t test it with top-level navigations, but can we test it for iframe navigations? The way I understand https://github.com/whatwg/html/pull/11454 iframe navs should also get the new behavior.


You can also test top-level navigations by opening popup windows. There are helpful frameworks for writing such tests, e.g., RemoteContextHelper.

Noam Rosenthal

unread,
Sep 3, 2025, 5:29:22 AM (2 days ago) Sep 3
to Domenic Denicola, Daniel Clark, Mustaq Ahmed, Chromestatus, blin...@chromium.org, vmp...@chromium.org
On Wed, Sep 3, 2025 at 1:59 AM Domenic Denicola <dom...@chromium.org> wrote:


On Wed, Sep 3, 2025 at 9:04 AM 'Daniel Clark' via blink-dev <blin...@chromium.org> wrote:

> I believe in WPT we can't have an a.html top-frame navigate to b.html and check things there.  I was not able to find an example in wpt/navigation-api/.  Did I miss anything?

 

I think it’s correct that we can’t test it with top-level navigations, but can we test it for iframe navigations? The way I understand https://github.com/whatwg/html/pull/11454 iframe navs should also get the new behavior.


You can also test top-level navigations by opening popup windows. There are helpful frameworks for writing such tests, e.g., RemoteContextHelper.

WPT uses popups extensively to test features that rely on top-level navigation. Navigation timing, render-blocking, cross-document view transitions come to mind as reference.
 

Alex Russell

unread,
Sep 3, 2025, 10:16:05 AM (2 days ago) Sep 3
to blink-dev, Noam Rosenthal, dan...@microsoft.com, Mustaq Ahmed, Chromestatus, blin...@chromium.org, Vladimir Levin, Domenic Denicola
LGTM1, conditional on the testing situation getting sorted to Dan and Domenic's satisfaction.

Best,

Alex

Reply all
Reply to author
Forward
0 new messages