New issue
Advanced search Search tips
Starred by 4 users

Issue metadata

Status: WontFix
Owner: ----
Closed: Aug 2015
Components:
EstimatedDays: ----
NextAction: ----
OS: Linux
Pri: 2
Type: Bug



Sign in to add a comment
link

Issue 165452: sessionStorage variables not being copied to new tab

Reported by rin...@gmail.com, Dec 11 2012

Issue description

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.
 
sessionstorage.zip
988 bytes Download

Comment 1 by tkent@chromium.org, Dec 11 2012

Labels: WebKit-Storage Area-WebKit

Comment 2 by michaeln@google.com, 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.

Comment 3 by niloy.mo...@gmail.com, Dec 12 2012

This behavior by Chrome is breaking our web application. We are storing our session identifier in session storage. Whenever we make ajax requests to server, we append the session identifier to the ajax call. Now, if a end-user right clicks on a link and opens in new tab, our application in the new tab asks for login again since the session variables are not being copied. But this is not what the end-user expects. So, now, we are forced to use cookies, which is like a step backwards :( . Please try to see this issue from an end-user perspective to understand the problem.

Also, the spec says to copy the variables.
Internet Explorer and Opera have implemented it right.
Firefox has accepted this as a bug: https://bugzilla.mozilla.org/show_bug.cgi?id=818389

Please realize Chrome is breaking an important use case here.

Comment 4 by michaeln@google.com, 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.

Comment 5 by bugdroid1@chromium.org, Mar 10 2013

Project Member
Labels: -WebKit-Storage -Area-WebKit Cr-Content Cr-Content-Storage

Comment 6 by bugdroid1@chromium.org, Apr 5 2013

Project Member
Labels: -Cr-Content Cr-Blink

Comment 7 by bugdroid1@chromium.org, Apr 6 2013

Project Member
Labels: -Cr-Content-Storage Cr-Blink-Storage

Comment 8 by jsb...@chromium.org, Apr 6 2015

Labels: -Cr-Blink-Storage Cr-Blink-Storage-DOMStorage

Comment 9 by michaeln@chromium.org, Aug 14 2015

Status: WontFix
claiming not-a-bug, if anybody sees it differently please repoen

Comment 10 by saleem...@gmail.com, 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.

Comment 11 by blepeu...@gmail.com, 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...

Comment 12 by t.avinas...@gmail.com, 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