Clarify cross-origin child frame named access on Window

[awesomekling]

What is the issue with the HTML Standard?

The current "document-tree child navigable target name property set" algorithm only appends a child navigable's target name when the child active document is same-origin with the parent Window's relevant settings object origin.

However, Chromium and Firefox both expose a cross-origin child WindowProxy through named access when the requested name matches the child frame's embedding element name content attribute. The returned object is still a cross-origin WindowProxy; this does not expose unrestricted access to the child Window or its DOM.

Example shape:

<iframe src="https://cross-origin.example/child1"></iframe>
<iframe name="frame2" src="https://cross-origin.example/child2"></iframe>

From child1:

parent.frames["frame2"].postMessage("...", "*");

This pattern is used by real sites, including reCAPTCHA-style iframe setups, where one cross-origin child looks up a sibling frame through parent.frames[name].

Chromium implements this in WindowProperties::AnonymousNamedGetter:

if (frame->GetSecurityContext()->GetSecurityOrigin()->CanAccess(
        child->GetSecurityContext()->GetSecurityOrigin()) ||
    name == child->Owner()->BrowsingContextContainerName()) {
  return ToV8Traits<DOMWindow>::ToV8(..., child->DomWindow());
}

For local frame owners, BrowsingContextContainerName() returns the frame owner element's name attribute.

Firefox implements the same basic thing in WindowNamedPropertiesHandler.cpp. Its ShouldExposeChildWindow() helper exposes same-origin child windows, and for cross-origin child windows returns true only when the requested name matches the embedder element's name attribute:

return e && e->AttrValueIs(kNameSpaceID_None, nsGkAtoms::name,
                           aNameBeingResolved, eCaseMatters);

Firefox's comment explains the compat tradeoff: filtering out all cross-origin subframes would break pages using:

<iframe name="foo" src="http://cross-origin.example/"></iframe>

...and expecting global named access to return the cross-origin subframe.

WebKit also exposes child frames by name before the DOMWindow security check, via scopedChildBySpecifiedName(), although its local implementation appears broader than the Chromium/Firefox embedder-attribute-only filter since window.name updates FrameTree::specifiedName.

Should the HTML Standard specify the Chromium/Firefox behavior for named access on Window, i.e. include cross-origin child navigables when the requested target name matches the navigable container's name content attribute?

Or is the current same-origin-only algorithm intentional despite this interop and web
compatibility behavior?