You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This is a follow-up of #1312 which I just merged; I should have asked this before merging.
The ordering of step 2's "later duplicates omitted" and step 3's removal of different-origin browsing contexts seems potentially suspect. Consider the following set of child browsing contexts of the active document, where the current origin is example1.com:
name = "a", origin = example2.com
name = "a", origin = example1.com
With this set, the result of running the algorithm after step 2, by my reading, is:
name = "a", origin = example2.com
(later duplicates being omitted. Assuming duplicates means duplicate names?)
Then, after step 3, we remove that list entry, because it is not same-origin. The result is that there are no child browsing context names. This seems unlikely to be intended.
Suggested solutions:
Clarify what "later duplicates being omitted" means. I don't think it's possible to have duplicate browsing contexts, so if this is based on "browsing context identity", then this sentence should be removed. If it's based on name, it should be clarified, e.g. "including only the first child browsing context with a given name if multiple child browsing contexts have the same one."
Is this behavior correct? If so, then clarification suffices. If not, then I'd suggest doing the duplicate name filtering at the last step. (Perhaps coupled with Clarify how "child browsing contexts" works #1336's suggestion of defining "a Window object's same-origin child browsing contexts"?)
The text was updated successfully, but these errors were encountered:
Follow up to #1312. Make “child browsing context name property set”
actually return browsing context names and clarify how the omitting
duplicates process works.
Fixes#1337 and fixes#1338.
Follow up to #1312. Make “child browsing context name property set”
actually return browsing context names and clarify how the omitting
duplicates process works.
Fixes#1337 and fixes#1338.
This is a follow-up of #1312 which I just merged; I should have asked this before merging.
The ordering of step 2's "later duplicates omitted" and step 3's removal of different-origin browsing contexts seems potentially suspect. Consider the following set of child browsing contexts of the active document, where the current origin is example1.com:
With this set, the result of running the algorithm after step 2, by my reading, is:
(later duplicates being omitted. Assuming duplicates means duplicate names?)
Then, after step 3, we remove that list entry, because it is not same-origin. The result is that there are no child browsing context names. This seems unlikely to be intended.
Suggested solutions:
The text was updated successfully, but these errors were encountered: