window.open and sessionStorage access by the opener
Reported by
blepeu...@gmail.com,
Apr 18 2017
|
||||||||||
Issue descriptionUserAgent: Mozilla/5.0 (Windows NT 10.0; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/57.0.2987.133 Safari/537.36 Steps to reproduce the problem: 1. Go to https://www.google.com/ 2. Open new window with the _same_ origin and assign a sessionStorage key _before_ the window is finished loading: w = window.open('https://www.google.com/'); w.sessionStorage['abc'] = 'XXX'; 4. Go to the newly opened window and try to read the key sessionStorage['abc'] ==> Access denied Uncaught DOMException: Failed to read the 'abc' property from 'Storage': access is denied for this document. at <anonymous>:1:15 What is the expected behavior? the newly opened window's sessionStorage should be readable and contain the key set in by the opener. What went wrong? When we access localStorage in the opener window, the newly opened window is not done loading, so I'm guessing the sessionStorage is "marked" with a different origin (about:blank), and when the new window finally loads, it cannot access the sessionStorage because it considers it from a different origin. And we get access denied on _any_ access to localStorage Did this work before? Yes 56.0.2924.87 Does this work in other browsers? Yes Chrome version: 57.0.2987.133 Channel: stable OS Version: 10.0 Flash Version:
,
Apr 18 2017
Just found a workaround: w = window.open(); w.sessionStorage['abc'] = 'XXX'; w.location = 'https://www.google.com/'; This works as expected
,
Apr 20 2017
Able to reproduce the issue on reported version #57.0.2987.133 and latest stable 58.0.3029.81 in Windows-10,Ubuntu14.04 and Mac OS 10.12.3. This is regression issue broken in M57 branch builds, below are the bisect details : Manual good: 57.0.2987.7 Manual bad: 57.0.2987.8 Unable to provide tool bisect as getting follwing runtime error 'RuntimeError: We don't have enough builds to bisect. revlist: [444943]' Hence providing manual changelog. Changelog URL: https://chromium.googlesource.com/chromium/src/+log/57.0.2987.7..57.0.2987.8?pretty=fuller&n=10000 Suspecting https://chromium.googlesource.com/chromium/src/+/e86ab7d65162a39b16e19710445f09e357c27a1e from changelog @varkha: Could you please look into this if it is related to your change or not. Please help in reassign if the change is unrelated. Thank you!
,
Apr 20 2017
Quoted CL is ash (Chrome OS) specific and the files are not included in the build on the affected platforms. Assuming the bisect link is correct, could it be https://chromium.googlesource.com/chromium/src/+/37eb3936671fb76468539fabd55c4c882b2f75f9 ?
,
Jul 31
,
Oct 15
Given the reimplementation that's happened here, we need to try and repro again.
,
Oct 15
,
Oct 18
Yeah, I ran the repro steps and got the same error using Mac 69.0.3497.100. Daniel, Victor mentioned you and mek@ are the current most knowledgeable for DOMStorage. Can you help us triage this bug further?
,
Jan 3
,
Jan 3
Putting back into our triage queue for our next round.
,
Jan 10
dmurph@ has worked most recently in SessionStorage. |
||||||||||
►
Sign in to add a comment |
||||||||||
Comment 1 by blepeu...@gmail.com
, Apr 18 2017