On 12/01/2016 06:14 PM, Elliott Sprehn wrote:
On Wed, Nov 30, 2016 at 10:53 PM, Boris Zbarsky <bzbar...@mit.edu> wrote:
On 12/1/16 1:41 AM, Chris Holland wrote:
I think the devil would be in implementation detail. Slapping a
"rel/noopener" attribute on a specific link is very deterministic and
straightforward from a logic standpoint ---- Whichever window was created
from this link can't control the parent.
It's a much stronger guarantee. The guarantee is that the parent and the
created window have no way to see each other at all. Neither one can read
any state from the other, or even know the other one exists.
In particular, the idea is that rel="noopener" allows the new window to be
opened in a separate process, or even a separate browser if desired. The
only difference between it and the user copying the link and then pasting
it into some other tab or other program is that a referrer header is sent.
Note that this guarantee makes for fairly simple implementation.
Having a header that opts in all links targeted at anything other than
_parent, _self, and _top have the noopener behavior would be doable. Having
a header that opts in some links based on the origin of the link href or
something would probably be doable. Having a header that tries to add some
sort of new mode wherein the two windows _can_ see each other but can't do
some things that they can normally do would be a snake pit of complexity
that is best avoided.
I would like us to think about adding a mode where you get a MessageChannel
between the two windows. There's no synchronous access, and no ability to
navigate it, but you can talk back and forth with it.
I haven't tried but I don't see why service workers couldn't be used for
that.
