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

[Chromestatus]

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]

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

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]

On Thu, Aug 28, 2025 at 9:45 PM Daniel Clark <dan...@microsoft.com> wrote:

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

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]

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

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.

To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/DS0PR00MB2342DC14AF7D4DA241E3F718C501A%40DS0PR00MB2342.namprd00.prod.outlook.com.

[Noam Rosenthal]

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]

LGTM1, conditional on the testing situation getting sorted to Dan and Domenic's satisfaction.

Best,

Alex

[Dan Clark]

LGTM2, also conditional on tests being added. Thanks for getting position requests filed (https://github.com/mozilla/standards-positions/issues/1295, https://github.com/WebKit/standards-positions/issues/547).

-- Dan

[Chris Harrelson]

LGTM3

--

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/17c109d3-e84f-4fdc-a755-c7020c7215e9n%40chromium.org.

[Mustaq Ahmed]

Because of a testdriver limitation we can't add a WPT at this point.  The test would require a click in the main window to open a popup w, then a click on  w to navigate the popup away.  Unfortunately, testdriver does not yet support both the clicks: test_driver.set_test_context(w) fails to switch the context to w, and without it a test_drive.click() on w is rejected and a test_driver.Actions.send() on w is ignored.

Here is a prototype test, the problems are mentioned in the main test comment.

[Domenic Denicola]

We've definitely gotten set_test_context() to work in the past; e.g. here is a CL that works (see executor.sub.html in particular, and some of the comments debugging earlier mistakes we made). But I also remember it being tricky.

+Jonathan Lee was able to help us with that test, and might be able to provide guidance if the sample CL above isn't enough.

[Mustaq Ahmed]

Forked the thread, and moved most people to bcc to avoid noise.

Hi Jonathan (and Domenic):

I already spotted executor.sub.html because that is the only test resource file to use test_driver.Actions().  Unfortunately, the main test file here (speculation-rules/prefetch/out-of-document-rule-set.https.html) does not use Actions() at all. In my case, I need Actions() on the main test file too, to avoid popup blockers.  Wondering why this was not needed in your case.

Mustaq

---

The original "Intent to Ship: Sticky user activation across same-origin navigations" thread follows.

---