New issue
Advanced search Search tips

Issue 767261 link

Starred by 2 users
Status: Duplicate
Merged: issue 765524
Owner: ----
Closed: Sep 2017
Cc:
jsb...@chromium.org
mek@chromium.org
Components:
EstimatedDays: ----
NextAction: ----
OS: Linux
Pri: 1
Type: Bug



Sign in to add a comment

LocalStorage removeItem() not propagating to different contexts

Project Member Reported by ralp...@google.com, Sep 21 2017 
Chrome Version: 61.0.3163.79
OS: Linux

What steps will reproduce the problem?
(1) Open a page, do localStorage.removeItem('key')
(2) Open the page again in a separate tab, and do localStorage.getItem('key')

What is the expected result?
Value should be deleted from the new page.

What happens instead?
Value is seen in the other page.
Deletions don't seem to propagate properly and consistently to other contexts.
Another context I tried is an iframe nested in an extension, and it also had keys that should have been deleted but only a subset of extra keys showed up there (compared to the example below).

I was able to reproduce this consistently on my main profile and on another existing profile. Could not repro in a new profile.

Comment 1 by mek@chromium.org, Sep 21 2017 

A (very speculative) possibility here would be that somehow the mojo connection between browser and renderer gets disconnected, after which changes made in one renderer won't propagate to any other renderer anymore. This shouldn't happen, but there are some (rare) situations where this might happen anyway. Not sure if that is what is going on here, but certain types of leveldb corruption could cause it. Chrome should recover from that though, and especially after restarting chrome the problem should be gone, which it doesn't sound like is happening here.

So not sure yet what's going on. I'll do more debugging later.

Comment 2 by mek@chromium.org, Sep 21 2017 

(random notes-to-self: there might also be bugs in the logic that decides when to evict LevelDBWrapperImpl instances. If that somehow decides to evict an instance still being used that could cause similar behavior. But not sure how that would happen)

Comment 3 by mek@chromium.org, Sep 22 2017

Mergedinto: 765524
Status: Duplicate (was: Untriaged)
►

Sign in to add a comment