New issue
Advanced search Search tips

Issue 732788 link

Starred by 3 users

Issue metadata

Status: Fixed
Owner:
Closed: Jun 2017
Components:
EstimatedDays: ----
NextAction: ----
OS: Android , Windows
Pri: 2
Type: Bug-Regression

Blocking:
issue 586194



Sign in to add a comment

localStorage data is not saved after tab closing

Reported by vsemozhe...@gmail.com, Jun 13 2017

Issue description

UserAgent: Mozilla/5.0 (Windows NT 6.1; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/61.0.3128.0 Safari/537.36

Steps to reproduce the problem:
1. open http://example.org/ and run in the Console:

localStorage['test'] = '123';
localStorage['test'];

You will get '123' and see the data in the Application -> Local Storage -> http://example.org/

2. Reload the page and run in the Console:

localStorage['test'];

You will get and see the same.

3. Do not close the page. Open a new tab with http://example.org/ and run in the Console:

localStorage['test'];

You will get and see the same.

4. Close all pages with http://example.org/. Open new tab with http://example.org/ and run in the Console:

localStorage['test'];

You will get 'undefined' and see no data in the Application -> Local Storage -> http://example.org/

What is the expected behavior?
Data is saved in the last case.

What went wrong?
Data is not saved in the last case.

Did this work before? Yes Some of the recent Canary build (1-2-3 build ago?)

Does this work in other browsers? Yes

Chrome version: 61.0.3128.0  Channel: n/a
OS Version: 6.1 (Windows 7, Windows Server 2008 R2)
Flash Version: 26.0.0.126

I use some bookmarklets that save data via localStorage, they have stopped working correctly.
 
This works as expected at least in the 61.0.3124.10 dev (64-bit).
This suspiciously consists with the https://bugs.chromium.org/p/chromium/issues/detail?id=732799
61.0.3129.0 still has the issue.

Comment 4 by mek@chromium.org, Jun 13 2017

Components: -Blink>Storage Blink>Storage>DOMStorage
Owner: mek@chromium.org
Status: Started (was: Unconfirmed)
Probably caused by 732863 (high error rate writing data to disk for new localstorage backend) and 712399 (no way to recover from data having failed to write to disk). Have some patches in flight that should hopefully land over the next few days to make things better.
Labels: OS-Android
I confirmed the reported (and incorrect) behavior on Android Chrome Canary just now:

Google Chrome	61.0.3129.0 (Official Build) canary (32-bit)
Revision	b7e12bae8572c1ed03d0959ed71df8e4efe2f8ee-refs/heads/master@{#478840}
OS	Android 7.1.1; Google Chromebook Pixel (2015) Build/R61-9627.0.0

mek@chromium.org - could this be due to your recent IPC changes?
On the same Chromebook, I don't see the buggy behavior in Chrome dev which is 61.0.3124.3

On my phone running a slightly older Chrome Canary build 61.0.3128.0 I also don't see the buggy behavior.
Hmm, possibly my earlier testing was flawed - maybe I ended up at https: rather than http: for one of the steps?

Comment 8 by mek@chromium.org, Jun 13 2017

Blocking: 586194
Today I've found out that 61.0.3132.0 had just absolutely wiped out all previous data from localStorage for many sites(

Comment 10 Deleted

See also  issue 733993 

Comment 12 by mek@chromium.org, Jun 17 2017

 Issue 733993  has been merged into this issue.

Comment 13 by mek@chromium.org, Jun 17 2017

I think with the latest canary (61.0.3133) things should start looking better, but unfortunately at least any changes made to localstorage while using any version after 61.0.3123 are likely going to be lost. And possibly older data from websites visited with one of those versions could also be lost.
Thank you for trying to fix this.

Comment 15 by mek@chromium.org, Jun 20 2017

Status: Fixed (was: Started)
As far as I can tell this should indeed be fixed in versions newer than 61.0.3133.
Verified with Chrome Dev 61.0.3136.3 using the  dev tool

Sign in to add a comment