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: tie-breaking for same-named top-level traversables is not interoperable #10850

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

Window name targeting: tie-breaking for same-named top-level traversables is not interoperable #10850

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 iterates over top-level traversables to find one with a matching name, in "find a navigable by target name". The effect is that if you have multiple such tabs with the same name, which one wins the tie is implementation-defined.

@kjmcnee states:

I can't remember the details, but I think Chromium and Firefox are based on creation order, or maybe reverse creation order. WebKit's ordering is arbitrary as it iterates over a hash set.

Chromium and Firefox's behavior seems better, at least, assuming they're both doing the same order. We should double-check the details, standardize on it, and write web platform tests.

For inspiration on how to write such tests, you can see Kevin's web-platform-tests/wpt#49631 .

Tests here that consistently fail on WebKit may be difficult to create, depending on how their hash works. Maybe something like creating 20 same-named top-level windows would work.
@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 <[email protected]>
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