[LNA] remove check for initiator being in the frame tree of the navigating frame.#59092
Draft
chromium-wpt-export-bot wants to merge 1 commit intomasterfrom
Draft
[LNA] remove check for initiator being in the frame tree of the navigating frame.#59092chromium-wpt-export-bot wants to merge 1 commit intomasterfrom
chromium-wpt-export-bot wants to merge 1 commit intomasterfrom
Conversation
…ating frame. This check was originally introduced in crrev.com/c/6763697 to only allow LNA permission prompts to trigger within a single tab/context. However, crbug.com/491509051 details a valid scenario where the initiator of a subframe navigation is not in the frame tree of the subframe being navigated. Specifically, this happens when: * top window (origin1) iframes origin2 * iframe of origin2 opens a new window, also to origin2 * new window of origin2 does `opener.location.href = <LNA-url>` With this fix, this scenario ends up checking the LNA permission on the initiator, which may pop up the permission prompt on the initiator window. This was chosen as it is the initiator which is triggering the LNA navigation. One quirk here: if instead of the opened window initiating the navigation, if instead it posted a message to the iframe that triggered the iframe to navigate itself, then the permission check would be on the iframe. This might lead to slightly different behaviour depending on permission policy settings, but is not a permissions bypass as the LNA permission is still required from an initiator in either case. Bug: 491509051 Change-Id: Iac1b4ded1459a61a93b9a6fdaf8278db529bf50b Cq-Do-Not-Cancel-Tryjobs: true
This file contains hidden or 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
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.
This check was originally introduced in crrev.com/c/6763697 to only
allow LNA permission prompts to trigger within a single tab/context.
However, crbug.com/491509051 details a valid scenario where the
initiator of a subframe navigation is not in the frame tree of the
subframe being navigated. Specifically, this happens when:
opener.location.href = \<LNA-url>With this fix, this scenario ends up checking the LNA permission on the
initiator, which may pop up the permission prompt on the initiator
window. This was chosen as it is the initiator which is triggering the
LNA navigation.
One quirk here: if instead of the opened window initiating the
navigation, if instead it posted a message to the iframe that triggered
the iframe to navigate itself, then the permission check would be on the
iframe. This might lead to slightly different behaviour depending on
permission policy settings, but is not a permissions bypass as the LNA
permission is still required from an initiator in either case.
Bug: 491509051
Change-Id: Iac1b4ded1459a61a93b9a6fdaf8278db529bf50b
Cq-Do-Not-Cancel-Tryjobs: true
Reviewed-on: https://chromium-review.googlesource.com/7681373
WPT-Export-Revision: cb3605f70989d7d63d3547862853fc398a5ff458