I see the same behavior in Firefox and IE and the ancient Chrome 31 so apparently window.open case is an exception. The question remains though whether this is a spec-regulated exception or just a historical quirk.

In edge, I've seen control click is keeping the sessionStorage but this ticket isn't about edge.

Could you please provide us any sample test file to triage the issue from test team end.

Thanks,

Included is a the test file that should be all the test cases for opening a new tab: ctrl-click, setting target on an anchor tag to _blank and, window.open attached to a button to open a new tab. Ctrl-click doesn't set the new window's sessionStorage but the other 2 test cases does.

Deleted: issue724718.html 601 bytes

issue724718.html 601 bytes View Download

Thank you for providing more feedback. Adding requester "kavvaru@chromium.org" to the cc list and removing "Needs-Feedback" label.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

Thanks for the html.

Tested the issue on windows 7 using chrome version 58.0.3029.110 with the below steps

1.Opened the attached html
2.Open Devtools application ,Session storage.Able to see the key value for the file://
3.Ctrl+Click on Link Open window with ctrl-click opened new tab 
4.clicked on Second link opened the new tab
5. Clicked on Window.open button opened the new tab
6.For all the cases observed the key value under session storage.

Could you please find the attached screen cast and confirm if anything missed here.
Request you please provide us any expected screen shot or video for better triaging the issue.

Thanks,

Deleted: 724718.mp4 1.6 MB

	724718.mp4 1.6 MB View Download

Attached is the a screen recorder. The first tab was opened by a ctrl-click, and looking into that tab, the session storage is cleared. The second tab is opened by a click on an anchor tag that target is set to _blank. The session storage is populated from the previous tab. The third tab is opened by a click on a button that opens a new tab by window.open whose target is set to _blank. The session storage is populated from the previous tab.

Deleted: 49ed8762b7c54afead867e8716374b40.mp4 2.7 MB

	49ed8762b7c54afead867e8716374b40.mp4 2.7 MB View Download

I am using Chrome Version 58.0.3029.110 (64-bit)

Thank you for providing more feedback. Adding requester "kavvaru@chromium.org" to the cc list and removing "Needs-Feedback" label.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

Able to reproduce the issue on windows 7, Ubuntu 14.04 and Mac 10.12.4 using chrome version 58.0.3029.110 and canary 60.0.3106.0.
This is non regression issue as the issue seen from M40 old builds.
Marking it as Untriaged to get more inputs from dev team.

Thanks,

I don't think this is a spec-regulated exception.

The relevant specification appears to be [1], which states that sessionStorage is tied to the current top-level browsing context, which is defined in [2]. According to [3], when window.open() is used for popup windows, it creates auxiliary browsing contexts. [4] states that all auxiliary browsing contexts are top-level contexts. Assuming I understand all of this correctly, the spec says that the document in the popup window should have a separate sessionStorage.

At the same time, if all the browsers have consistent behavior, it might be better to update the spec. 


[1] https://html.spec.whatwg.org/multipage/webstorage.html#the-sessionstorage-attribute
[2] https://html.spec.whatwg.org/multipage/browsers.html#top-level-browsing-context
[3] https://html.spec.whatwg.org/multipage/browsers.html#dom-open
[4] https://html.spec.whatwg.org/multipage/browsers.html#auxiliary-browsing-context

Assigning to myself for browser compat testing.

In fact sessionStorage is copied, not shared. Verify this yourself using this JS snippet in an http(s)-hosted website:

(setup=>setup(self,document,setup))((win,document,setup)=>{var a=String.fromCharCode(0x61+(Math.random()*26)|0);document.open();var d=new Date;document.write('<title>'+d+'</title><h1>'+d+'</h1><button id=update>↻</button><button id=pop>↗</button><button id=x>x</button><div id=display></div>');document.close();document.getElementById('update').onclick=()=>win.sessionStorage.nonce=(0x7fffffff*Math.random())|0;document.getElementById('pop').onclick=()=>win.open('about:blank','_blank',String(['width=400','height=300'])).setTimeout(function(){setup(this,this.document,setup)});document.getElementById('x').onclick=()=>win.close();win.setInterval(()=>{document.getElementById('display').innerHTML=win.sessionStorage.nonce;win.sessionStorage.nonce+=(' '+a)},1e3);})

Pop up a window with the pop button (↗) and notice that while the storage starts out identical, it quickly diverges.

The question isn't if it's shared or copied, the question is about should the test cases mention above be treated the same or different.

Apologies for the delayed response, I neglected to cc myself. Thanks for following up with me, pwnall@chromium.org !

The result of window.open is not exactly a new tab in the same sense as the result of control-click is.

In general control-click and window.open are not equivalent. 

I didn't see it as a spec inconsistency because the spec doesn't actually say when cloning does/doesn't happen, so far as I can tell. The spec also doesn't specify that window.open and ctrl-click are equivalent, so far as I can tell. Separately from spec issues, it's possible MDN's explanation is somewhat incomplete or oversimplified and would benefit from elaboration.

Clarification: I think a lot of window.open behavior (both as specified and as implemented) is basically a legacy of the early days (before tabbed browsing) and the tab-like rendering of its results (though only under some conditions!) is coincidental

Completely understood it isn't specify now and completely agree with your statement.
I guess the question becomes, as a web community, should we provide specs related to this? 

Currently, I'm the front end developer for a small company and saw this behavior inconsistent between browsers, specifically Edge/IE11 vs Chrome/Firefox. We currently use sessionStorage as a place to store the current user session and if it's null, kick them over to the login page. If we have a ctrl-click action, and the href is setup to a nested route, we lose the sessionStorage information thus forcing them through the login page. This where this ticket came from. We like sessionStorage for the specific reason of keep information for the life of a session but these browsers inconsistency killed the idea of sessionStorage.

Just a thought.