Preserve sticky user activation across same-origin navigations - #63952

Why does it fail on iOS?

@annevk

Both tests rely on test_driver.click() to give the popup window user activation before navigating it. PR #63430 enabled popup-window click dispatch via eventSender, but only for the non-iOS path. the iOS WK2 path goes through iController.singleTapAtPoint, which targets the main test view only and has no popup-view-aware equivalent, so it was not covered by that fix. As a result, on iOS the test's precondition never holds. The popup never reaches the activated state, and the assertions about preserving sticky activation across navigation can't be exercised. The tests fail at the activation setup step, not at the behavior we're shipping.

Also, this matches a pre-existing convention in LayoutTests/platform/ios/TestExpectations, which already groups several user-activation WPTs under the comment:
# UserActivation tests rely on test_driver.click() which is not supported on iOS

The two new tests (navigate-to-sameorigin.html, navigate-to-crossorigin-redirect.html) are skipped under that same group for the same reason.

This needs some kind of explanation as to why this is not a regression.

Thank you for the careful review.

My reading of the spec PR discussion is that sticky activation preservation is intended to apply per-frame, including iframes. In particular, the response in LINK to the question of restricting it to top-level only leans against that restriction:
"I'm less sure about this. My instinct was to just do whatever was easiest to spec/implement, which in this case was to allow it to work in iframes."
and in LINK
"On iframes, it seems simpler to just allow those navigations to carry over sticky activation."

Based on those, my implementation in DocumentWriter::begin() applies uniformly to both top-level and iframe navigations.

About navigation-state-reset-sameorigin.html: this test exercises a same-origin iframe navigation (not top-level) and asserts that sticky activation is reset — which I read as reflecting the pre-spec-change behavior. Under my reading of the new spec, sticky activation should be preserved in iframe navigations as well, so the test's existing assertion no longer holds. The expected.txt update to FAIL documents this transitional state until WPT upstream is updated to match the new spec.

If you read the spec discussion differently, please let us know — happy to revisit the scope.
Thanks again!

This is not robust. In theory the URL could be the same, but a redirect could have taken place due to a cookie or some such.

I'm also not sure this is the correct place to make this overall check. Maybe @youennf can give some pointers.

Thanks for catching this. I hadn't accounted for that case. I'll revisit the redirect detection and follow up with an updated patch.

Thanks.

@annevk

Addressed both concerns in the latest push:

1. Redirect detection is no longer based on URL equality between originalURL() and responseURL(). The check now uses NetworkLoadMetrics::hasCrossOriginRedirect, which is set to true whenever any step in the redirect chain crosses an origin boundary (regardless of whether the final URL happens to match the start URL). This correctly handles A → B → A patterns and stops blocking legitimate same-origin internal redirects.

2. Additionally added a check that the navigation is renderer-initiated. Browser-initiated navigations (address bar typing, bookmarks, history navigation, embedder API loads) now suppress carry-over via DocumentLoader::isRequestFromClientOrUserInput(). This aligns with Chromium's behavior.

Regarding your second comment (whether DocumentWriter::begin() is the right place for this check) — with the URL-equality removed, the check now reads only from the navigation's own DocumentLoader (initiator flag, redirect metrics) and the previous Document/Window (origin, sticky activation). All of this is per-Document state that is naturally available at navigation commit time. Happy to revisit the location if you still see a better fit.

Not in this PR (planned follow-up): The spec discussion also calls for the carry-over to apply when a document is reactivated from the back/forward cache, so that behavior remains consistent between bfcache hits and misses. This PR only updates the "create new document" path (DocumentWriter::begin()); WebKit's bfcache restore path is a separate code site that I plan to address in a follow-up once the spec text for the reactivate algorithm is finalized.

This WPT now requires preserving sticky activation in subframes too — will update WebKit accordingly:
https://github.com/web-platform-tests/wpt/pull/60008/changes