Mention sessionStorage copying in logic for creating auxiliary browsing contexts

[mystor]

When opening a new auxiliary browsing context, SessionStorage defines its behavior (that the Storage object is copied, but not shared with, the new toplevel window) here: https://html.spec.whatwg.org/multipage/webstorage.html#the-sessionstorage-attribute

This is not mentioned in the logic flow for creating a new auxiliary browsing context, for example, in the named window resolution logic here: https://html.spec.whatwg.org/multipage/browsers.html#noopener. This creates some spooky action-at-a-distance where sessionStorage logic must be run in this codepath but is not mentioned.

This should be refactored so that the sessionStorage behavior is mentioned when creating a new auxiliary browsing context (probably here: https://html.spec.whatwg.org/multipage/browsers.html#creating-a-new-browsing-context).

cc @annevk

[mystor]

Another note: when opening a new window with noopener, we currently follow all steps for creating a new window, including copying sessionStorage from the existing window into the new window. This seems undesirable as we want noopener to imply that the opened window is not an auxiliary browsing context (from my understanding). I imagine that web developers would not expect a new window opened with noopener to get a copy of sessionStorage from the original window.

This is currently the behavior in both Chrome and Firefox (haven't tested any other browsers).

[mystor]

Also cc-ing @bzbarsky re the second comment above, as he probably has thoughts.

[annevk]

cc @mikewest

[bzbarsky]

Ideally we wouldn't copy sessionStorage for the noopener case, yes. Not sure about the noreferrer case; again ideally it would work that way but webcompat is worrisome.

[mikewest]

I agree with both @mystor and @bzbarsky that we probably shouldn't be copying sessionStorage over to the newly created noopener window. I bet we can get away with doing the same for noreferrer, since this is a fairly niche case.