Browsing context sandboxing and user indicated targets for links etc. (e.g Ctrl-click)

[bobowen]

This is re a user forcing a link within a sandboxed browsing context (without allow-popups) to be opened in a new tab (via Ctrl-click, right-click->"Open Link in New Tab", etc.)

Firefox does allow this as per the spec (because the spec only checks the sandboxed auxiliary navigation browsing context flag in [1], which doesn't get run when the user has specified the target).

Because of the way that sandboxing affects the navigation algorithm, the spec was also changed so that the "one permitted sandboxed navigator" was set on the new top-level browsing context (see [2] step 3 and [3] step 8->2).
Otherwise you would open a new tab and the sandboxed source browsing context would not be able to navigate it.

In Firefox Ctrl-clicking (etc.) a link acts as if the user had opened the new tab and typed the URL themselves.
This still gives you the (deliberately allowable) escape from the sandbox, but the one permitted sandboxed navigator and window.opener do not get set.

Given that this is a sandbox escape, it seems reasonable that the links with the previous browsing context are severed as in Firefox.
So, it would be good if the spec could be changed to reflect this.

Copying in @annevk

For more context also see:
https://www.w3.org/Bugs/Public/show_bug.cgi?id=26317

[1] https://html.spec.whatwg.org/multipage/browsers.html#browsing-context-names:sandboxed-auxiliary-navigation-browsing-context-flag
[2] https://html.spec.whatwg.org/multipage/semantics.html#following-hyperlinks-2
[3] https://html.spec.whatwg.org/multipage/browsers.html#dom-open

[domenic]

@mikewest, any thoughts on this?

[mikewest]

Seems reasonable to both avoid setting opener and to hop out of the sandbox if the user initiates the navigation into a new window/tab. I'm pretty sure Chrome treats ctrl-click similarly to how @bobowen says Firefox works.

[mikewest]

Quick experimentation shows that Chrome treats ctrl-click differently from the "Open in new tab" context menu item for a link inside <iframe sandbox>. Not sure that makes sense. We should probably pick one behavior or the other. Aligning with Firefox is probably reasonable.

[domenic]

Great! @bobowen, since this area is somewhat outside my area of expertise, could you describe the specific spec changes you'd expect? What sections would get what kind of sentences added or removed?

Maybe @annevk would be able to help here too.

[bobowen]

Yes, I can look into this, but it will be some time next week at the earliest.
I think the notes from the previous bug should help me find the places to change.

[annevk]

I guess now https://bugs.chromium.org/p/chromium/issues/detail?id=658386 is fixed Chrome really aligns with Firefox?

This should be easier to fix once #2618 lands as that revamps the browsing context choosing algorithm a bit.

I basically want to get to a point where we explicitly allocate a "unit of related browsing contexts" (maybe "browsing context group" after "tab group" in Firefox) at which point fixing this would be fairly easy. See also #1440.