Fix selectURL() loaded iframes not getting window.fence. #50394
+51
−13
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
We are temporarily allowing APIs like Protected Audience and Shared Storage selectURL() to load into iframes as part of the fenced frame transition process. As part of this, we expose the fenced frame window.fence call to these kinds of iframes. This was launched as part of the fenced frames launch. See: https://chromestatus.com/feature/5699388062040064 A restriction currently exists where the config created by the API must have some kind of reporting metadata to give the iframe access to window.fence. This is a legacy restriction and is no longer necessary, and it results in selectURL()-created iframes without reporting metadata supplied from accessing window.fence. This CL fixes that by removing the restriction. It also adds a test to check the selectURL() without reporting path. It also updates the fenced frame WPT infrastructure to allow selectURL() to be invoked with or without reporting metadata. As part of this change, the renderer is no longer being told whether the fenced frame has reporting metadata. This is information that can be determined in the browser rather than calculating it on the renderer-side and then verifying the calculation in the browser, so having the renderer be part of this check is unnecessary. Change-Id: Ieec3cdaa31cd62bfe6fdb1993e13d68f00f00f28 Bug: 392650252 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/6197762 Reviewed-by: Shivani Sharma <[email protected]> Commit-Queue: Liam Brady <[email protected]> Reviewed-by: Arthur Sonzogni <[email protected]> Reviewed-by: Daniel Cheng <[email protected]> Reviewed-by: Xiaochen Zhou <[email protected]> Cr-Commit-Position: refs/heads/main@{#1413688}
wpt-pr-bot
approved these changes
Jan 30, 2025
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
We are temporarily allowing APIs like Protected Audience and Shared
Storage selectURL() to load into iframes as part of the fenced frame
transition process. As part of this, we expose the fenced frame
window.fence call to these kinds of iframes. This was launched as part
of the fenced frames launch.
See: https://chromestatus.com/feature/5699388062040064
A restriction currently exists where the config created by the API must
have some kind of reporting metadata to give the iframe access to
window.fence. This is a legacy restriction and is no longer necessary,
and it results in selectURL()-created iframes without reporting metadata
supplied from accessing window.fence.
This CL fixes that by removing the restriction. It also adds a test to
check the selectURL() without reporting path. It also updates the fenced
frame WPT infrastructure to allow selectURL() to be invoked with or
without reporting metadata.
As part of this change, the renderer is no longer being told whether the
fenced frame has reporting metadata. This is information that can be
determined in the browser rather than calculating it on the
renderer-side and then verifying the calculation in the browser, so
having the renderer be part of this check is unnecessary.
Change-Id: Ieec3cdaa31cd62bfe6fdb1993e13d68f00f00f28
Bug: 392650252
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/6197762
Reviewed-by: Shivani Sharma <[email protected]>
Commit-Queue: Liam Brady <[email protected]>
Reviewed-by: Arthur Sonzogni <[email protected]>
Reviewed-by: Daniel Cheng <[email protected]>
Reviewed-by: Xiaochen Zhou <[email protected]>
Cr-Commit-Position: refs/heads/main@{#1413688}