UserAgent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.11 (KHTML, like Gecko) Chrome/23.0.1271.95 Safari/537.11 Steps to reproduce the problem: 1.Created a page "page1.html" with stores some values in sessionStorage. 2. Created a anchor link on page1.html that points to "page2.html" in the same domain. 3. Right click on the page2 anchor and select "open in new tab" Attached Files for testing What is the expected behavior? The session variables in page1.html should have been "copied" to page2.html as per the spec. Opera does this. This is required for web applications using sessionStorage to work correctly with "open in new tab". What went wrong? page2.html does not have any session variables that were created in page1.html Did this work before? No Chrome version: 23.0.1271.95 Channel: stable OS Version: Please extract the zip to a http server and open page1.html Opera and Internet explorer implemented this properly.
Dec 11 2012,
Dec 12 2012,
I'm not so sure I agree this is a bug. I think Opera may have a bug. If the <a> link itself has been setup to open in a new tab or window by having a target attribute, session storage values are copied over. They're also carried over if the means of opening the new tab/window is window.open(). But right clicking and saying 'open in new tab' is short-hand for creating a new tab and navigating that tab to the url in the link. When following those manual steps, session storage values should not and are not be copied over.
Dec 12 2012,
Dec 14 2012,
If Firefox implements the right-click-open-in-tab gesture in this way, that would be compelling and we should probably follow suite too for the sake of compatibility. But I beg to differ that the spec says to copy in this case. There are a variety of ways to pull a url out of a page in tab A and get some other tab B to navigate to it. Right click 'open in new tab' is but one of them. - right click copy link address, paste in address bar - drag-n-drop link into the address bar to creat a new tab - drag-n-drop link into an existing tab Is it a good thing to special case that one particular gesture you brought up and not the others? In the latter of those, there's an existing session storage area in existing tabs, which one wins the new clone or the existing area? Sounds like you're trying to use SessionStorage as a direct replacement for session cookies, but 'session' has different meanings between those two things. In the DOMStorage case, it implies tab specificity in the cookies case it does not.
Mar 10 2013, Project Member
Apr 5 2013, Project Member
Apr 6 2013, Project Member
Apr 6 2015,
Aug 14 2015,
claiming not-a-bug, if anybody sees it differently please repoen
Nov 23 2016,
All the discussions and specification from https://www.w3.org/TR/webstorage/#the-sessionstorage-attribute are great. But, since storing data in sessionStorage is advanced and more efficient compared to cookies and what we perceive when we talk about "session" is a set of pages user navigates in the site before closing browser, it would be nice and more useful if we add 3rd parameter like sessionStorage.setItem(name, "foo", "persist") to allow passing this data even in new tabs or possibly window. If this 3rd param is not given, we can initiate new session in new tab which is current behaviour. This will greatly benefit numerous banking sites and critical applications which will expect nice API to set and retrieve session data instead of writing lots of code to set and get from cookies. It's just a suggestion that w3.org accept this and all browser vendors implement this kind of API. It will be win-win for all involved.
Dec 12 2016,
A little late to the party here, but I think this issue should be re-examined. It might not be a bug per se, as the spec isn't very specific, but I believe it is contrary to the expected behavior. Specifically, opening in a new tab, or middle-clicking a link, does not start a new navigation from scratch. Both gestures do a navigation. Whether it is in a new tab or in the same tab should be irrelevant. The middle-click allows a fork in the current navigation, but it has a history. For instance, the new page has a referrer (other ways of pulling a page in a new tab don't). So it is not equivalent to opening a new page and pasting the new url in it. (and I could have sworn that the new opened tab had a history, but apparently it hasn't - I think that's wrong too) I believe the sessionStorage should mimic the browser's history behavior, and that _both_ should not care if we left-click or middle-click on a link. It's still navigating from one page to another, and as such should carry over the state of the navigation (just like "duplicate tab" does). Not holding my breath though, because all three major browser must have the same behavior for it to be relied upon...
Aug 28 2017,
I understand that right click and open in new tab is same as copying and pasting a url in a new tab. But i need a way to preserve session storage when the user right clicks a link and opens in a new tab. Session storage in IE stores session storage data when we right click and open a link but that is not the case with mozilla or chrome.
Sign in to add a comment