Add spec for _unfencedTop navigation target. #200
Conversation
spec.bs
Outdated
| <tr> | ||
| <th rowspan=2>Keyword</th> | ||
| <th rowspan=2>Ordinary effect</th> | ||
| <th colspan=2>Effect in an <code>iframe</code> with...</th> |
There was a problem hiding this comment.
Are these correct? I think with our current implementation, the _unfencedTop target only works for API-created fenced frames. Everything else (including default constructor created fenced frames) will open it in a new context (as if the keyword was a "name that doesn't exist".
Is the intention to have _unfencedTop work from all frame types? Or just within fenced frames? Or just within API-created fenced frames? That will determine if the spec needs to change or the impl needs to change. Based on the "the rules for choosing a navigable" patch below, it looks like the intention is to only have this work from within fenced frames.
There was a problem hiding this comment.
I ported #174 from gtanzer as-is, so I need to dig more into what the actual behavior in Chromium is. Let's chat offline and get back to this comment after.
There was a problem hiding this comment.
Based on our offline conversation, it sounds for non-fenced frames, _unfencedTop should be treated as a "name that doesn't exist" and just open a new context. So I think the table would end up being:
new, maybe new, maybe new, current
new, maybe new, maybe new, outermost top
Side note, _unfencedTop if outermost top is current and Effect in a fenced frame would realistically never be hit, but there are some other cases in the existing table that are also impossible to hit (like _top if top is current and iframe with *) so it's probably fine to keep.
This is a rewrite of #174, converting the rough outline for the _unfencedTop navigation target spec into a formal patch.
Preview | Diff