Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Window name targeting: which subtree to search is not interoperable #10848

Open
domenic opened this issue Dec 11, 2024 · 0 comments
Open

Window name targeting: which subtree to search is not interoperable #10848

domenic opened this issue Dec 11, 2024 · 0 comments
Labels
interop Implementations are not interoperable with each other topic: frames/navigables/browsing contexts

Comments

@domenic
Copy link
Member

domenic commented Dec 11, 2024

What is the issue with the HTML Standard?

After #10818 merges, we will have an implementation-defined step which establishes subtreesToSearch in "find a navigable by target name".

@kjmcnee states:

WebKit and Chromium search the requesting window's subtree then search from the top. Firefox iterates and searches from each ancestor. If there's a way to express in the spec that the implementation-defined behavior is fixed for the instance of the user agent, then that'd be appropriate here.

We should probably standardize on the 2/3 behavior here, unless Gecko has a strong argument for why theirs is better. This issue tracks doing so.

The only hard part will be writing appropriate web platform tests. For inspiration on how to write such tests, you can see Kevin's web-platform-tests/wpt#49631 . We just need to establish a setup where the two strategies give different results and then assert the WebKit/Chromium behavior.
@domenic domenic added interop Implementations are not interoperable with each other topic: frames/navigables/browsing contexts labels Dec 11, 2024
@domenic domenic mentioned this issue Dec 11, 2024
Merged
6 tasks
domenic added a commit that referenced this issue Dec 12, 2024
@kjmcnee @domenic
Make named window lookup more precise and correct BCG swap logic
f23f559 
In "the rules for choosing a navigable," the method to find an existing navigable by name is vague. This updates the definition to accurately reflect what the major implementations do. There are some differences between implementations, so there remains in the spec some optional/implementation-defined behavior, but it's much narrower. In particular, note that lookups are now explicitly scoped to browsing context groups. The previous language in the named lookup about "the user agent determines that the two browsing contexts are related enough" is now no longer a part of the lookup logic, but a consequence of the BCG swap decisions.

In "obtain a browsing context to use for a navigation response," the existing spec only mentions COOP enforcement as a reason to do a browsing context group swap. Some implementations perform a swap for additional security and performance reasons. This is now reflected in the spec.

For context, see:

* #313
* #4198 (comment)
* #5350

This closes #313, but we have opened the following issues to track the remaining implementation-defined interop gaps: #6356, #10842, #10848, #10849, #10850.

Co-authored-by: Domenic Denicola <d@domenic.me>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
interop Implementations are not interoperable with each other topic: frames/navigables/browsing contexts
Milestone
No milestone
Development

No branches or pull requests
1 participant
@domenic