I cannot reproduce, either using localhost:3002, or using this URL -
http://run.plnkr.co/Ibitu6lJaFOXX4A3/

Chrome 55 on Windows 7.

Does the mentioned URL trigger it for you?

Initially that URL worked and I was not able to reproduce it in my main Chrome session. I originally reproduced the issue in a separate Chrome session with "--user-data-dir".

When I tried to reproduce it in the separate session the URL suddenly gave me a "not found" error. Maybe I requested it too often?

I guess it was a temporary URL.
This is how I created it -
Go to this URL -
http://plnkr.co/edit/vJMM1Y?p=preview
Click on the full screen button near the top right corner, copy the URL of the popup.

> According to the spec window.sessionStorage is unique per tab/window

Not quite. If a window opens another window (popup or tab), they share the same session, and session is preserved across navigations.

But I think that's irrelevant to the repro here; manually opening a new tab and pasting a URL should indeed be a new session, insofar as I understand things.

I can't seem to repro - can you elaborat step 4?
"4. Spam CTRL-T (open new tab), CTRL-V (paste URL in address bar), Enter (open URL) to create a lot of tabs with the same page."

I'm spamming ctrl-t,ctrl-v,enter over and over, is that what you mean?

I'm unable to repro so far. How consistent is this happening?

I can report that this problem is not consistently reproducible.

So far I haven't been able to reproduce it with the run.plnkr URL, but I have been able to reproduce it on my local Apache server.

For the heck of it I put the file on my own external web server, and I can reproduce the issue there. Try this:

http://www.jboer.nl/temp/test.html

1. I opened a new tab in my current Chrome session (the same one I'm using to post this response) and pasted the URL. "test set to:" as expected.

2. Then I pressed CTRL-T followed by CTRL-V followed by Enter and repeated that until I had "a bunch" (anywhere between 10-30 tabs) open.

3. Then I went back to the first tab and pressed "close all to the right". At this point only 1 tab was open with that URL set.

4. I immediately pressed CTRL-T followed by F12 to open a new tab and the Developer Tools window. I then used the mouse to click back in the address bar (focus goes to the Developer Tools console by default) and pressed CTRL-V followed by Enter. Result: "test variable already exists!" The number shown is NOT the same number as in the tab left open after step 3, so I'm guessing a session is being reused somewhere.

Can you reproduce it with the above URL?

Video evidence: http://recordit.co/NthEFGicOI

yup, this happens readily with http://www.jboer.nl/temp/test.html

i think if you alter the steps to close the devtools prior to navigating the newly created tab, the bug does not manifest

I have only managed to reproduce it with the DevTools window open. That's how I initially discovered the bug: during development sessionStorage variables would leak into my new session.

test set to: 597
test set to: 432
test set to: 505
test variable already exists! value = 252

Looks like the page is being loaded multiple times, once invisibly to the user, and the second load picks up the artifacts of the first. In my poking at this, the existing value is never one that was actually seen before.

You don't need the inspector for the bug to happen. Here's more reduced steps to repro.

* start browser
* paste "http://www.jboer.nl/temp/test.html" into addr bar but don't enter
* activate any other window (or open devtools)
* re-active the browser window
* hit enter to navigate the the test.html page
* test variable already exists! value = XXX

I think DevTools might be an innocent bystander.

Preload, perhaps?

That's possible. When DevTools is open, we'll never swap in a prerender. But the prerender itself will still keep running and share the same sessionStorage namespace as the parent tab, which means you'll see the page loading twice. (Or, worse, in parallel.) This seems somewhat fundamentally unfixable without just removing prerender, which badly needs to happen and I believe is underway.

When DevTools is closed, the bug is probably being masked because the prerenders just get swapped in.

A net-internals log should confirm whether prerender is happening:
https://dev.chromium.org/for-testers/providing-network-details

The two renderings are being performed in different processes.

#13 and #14 reinforce what i was thinking. I'll look at what prerendere_manager.cc is doing?

yup, AutocompleteActionPredictor::CancelPrerender when you switch out of the tab or deactivate/reactivate the window.

I think we 'wont fix' this and wait for prerender to go away.

if anybody disagrees, please speak up and reopen the bug