New issue
Advanced search Search tips

Issue 780360 link

Starred by 2 users
Status: Fixed
Owner: ----
Closed: Nov 12
Cc:
mek@chromium.org
dmu...@chromium.org
Components:
EstimatedDays: ----
NextAction: ----
OS: Linux , Windows , Mac
Pri: 2
Type: Bug

Blocked on:
issue 271996


Sign in to add a comment

storage event is not dispatched on file:// protocol even though storageArea is shared

Reported by tristan....@gmail.com, Nov 1 2017 
UserAgent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:57.0) Gecko/20100101 Firefox/57.0

Steps to reproduce the problem:
1. Open the attached html file in two separate tabs (Tab#1 & Tab#2) from the file:// protocol
2. Open the dev console in both tabs
3. click "set storage" on the Tab#1
4. click "get storage" on the Tab#2

What is the expected behavior?
Either the there is a security measure avoiding both tabs to communicate, in which case Tab#2 should not share Tab#1's storageArea, 
either they there is no security measure and the storage event should fire on Tab#2.

What went wrong?
Tab#2 didn't receive the storage event, but is able to read localStorage.foo set by Tab#1.

Did this work before? N/A 

Does this work in other browsers? Yes

Chrome version: 62  Channel: n/a
OS Version: OS X 10.12
Flash Version: 

Not sure if it should have been marked as security or not... FF does just allow shared storageArea on file:// protocol.
storage_bug.html
398 bytes View Download

Comment 1 by krajshree@chromium.org, Nov 1 2017

Labels: M-64 Needs-Triage-M62 OS-Linux OS-Windows
Status: Untriaged (was: Unconfirmed)
Able to reproduce the issue on Mac 10.12.6, Win-10 and Ubuntu 14.04 using chrome stable version #62.0.3202.75 and latest canary #64.0.3254.0.
This is a non-regression issue as it is observed from M50 old builds. 

Hence, marking it as untriaged to get more inputs from dev team.

Thanks...!!

Comment 2 by jsb...@chromium.org, Nov 3 2017

Blockedon: 271996

Comment 3 by jsb...@chromium.org, Nov 10 2017

Components: -Blink>Storage Blink>Storage>DOMStorage
Labels: -Needs-Triage-M62
Status: Available (was: Untriaged)
Project Member

Comment 4 by sheriffbot@chromium.org, Nov 12

Labels: Hotlist-Recharge-Cold
Status: Untriaged (was: Available)
This issue has been Available for over a year. If it's no longer important or seems unlikely to be fixed, please consider closing it out. If it is important, please re-triage the issue.

Sorry for the inconvenience if the bug really should have been left as Available.

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

Comment 5 by mek@chromium.org, Nov 12

Status: Available (was: Untriaged)

Comment 6 by mek@chromium.org, Nov 12

Cc: mek@chromium.org dmu...@chromium.org
Status: Fixed (was: Available)
Actually, this seems to have been "fixed" by onion-souping domstorage. I do believe eventually we would want to just make all file:// URLs have opaque origins and thus no shared domstorage, but for now this bug seems to be fixed.
►

Sign in to add a comment