1017066 - localStorage and sessionStorage corrupted / unavailable after browser update, before restart

Status: RESOLVED WORKSFORME

(Firefox :: Untriaged, defect)

Description

[Dan Callahan [:callahad]]

Sometimes, localStorage and sessionStorage objects cease functioning. This appears to occur after a browser update, and has been observed on Fx 29 through Fx 32, on 64 bit OS X and Ubuntu.

I have not managed to deterministically repro this bug, though I have experienced it firsthand.

CarlFK on IRC just experienced this bug on Fx 29.0, running on 64-bit Ubuntu 14.04 LTS.

Symptoms:

- After performing `apt-get update && apt-get upgrade`, Persona started showing him an "Unsupported Browser" error message, which was rooted in broken localStorage support.

- When visiting the Persona Troubleshooting page at https://people.mozilla.org/~fmarier/troubleshoot.html, it reported that his browser defined both localStorage and sessionStorage, but that it did not support either.

- In the Web Console for that page, `window.localStorage` prints `[object Storage]` instead of the expected `Storage { length: 0 }` pretty-printing.

- Attempting `window.localStorage.setItem('foo', 1)` yields `[Exception... "Component returned failure code: 0x8052000b (NS_ERROR_FILE_CORRUPTED) [nsIDOMStorage.setItem]"  nsresult: "0x8052000b (NS_ERROR_FILE_CORRUPTED)"  location: "JS frame :: debugger eval code :: <TOP_LEVEL> :: line 1"  data: no]`

- Everything works as expected in a new Private Browsing window.

- After restarting the browser (to complete the upgrade), everything works as expected.

Carl's UserAgent string was "Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:29.0) Gecko/20100101 Firefox/29.0" when he experienced this bug. I've seen it on Nightly.

Comment 1

[Gene Wood [:gene]]

Mark Jeffries also repro'd this Firefox bug when upgrading from Firefox 29.0 to 29.0.1 and using Persona. I observed it at his desk. Same exact sequence of events and output (though I didn't explicitly test localStorage)

Comment 2

[Dan Callahan [:callahad]]

This may be unrelated to upgrades. According to Gene, "mjeffries experienced that firefox version is not supported issue again but this time *not* while he is in between firefox updates"

Comment 3

[Gene Wood [:gene]]

False alarm with mjeffries. His Firefox profile was somehow corrupted and he had been restoring his profile each time he had to shutdown firefox by pulling it from backups. I had him create a new profile and migrate his content over using sync and the problem doesn't happen. The issue is still constrained to what :callahad identifies above.

Comment 4

[Justin [:JW_SoftvisionQA]]

Is it safe to say this bug can now be closed?

Comment 5

[Mark Jeffries]

I'm good on my end.

Comment 6

[ravi.jaiswal]

I am seeing some of the customers are reporting following error NS_ERROR_FILE_CORRUPTED when             localStorage.SetItem(key, value) is invoked. UA: Mozilla/5.0 (Windows NT 6.1; rv:41.0) Gecko/20100101 Firefox/41.0. Is there a workaround for this?

Comment 7

[Justin [:JW_SoftvisionQA]]

Hey Mark,

Can you help with this issue?

Comment 8

[ravi.jaiswal]

Bug 1055496 seems related to this.

Comment 9

[Paul Oiegas [:poiegas], PM for (Ecosystem QA, Services QA, WebCompat QA, Hubs QA teams)]

Hi guys,

I have tried to reproduce this issue on latest Firefox release (44.0) and latest Nightly build (47.0a1-20160202030232) but I haven't managed to. Installed the previous 43.0.4 release and Nightly 46.0a1 and performed the update without restarting the browser to complete it. Executed the mentioned commands in web console but I haven't got the excecptions mentioned by Dan or Ravi. 

Used a MacBook Pro Retina 13" (early 2015) with Mac OS X 10.10.5 to test this. 

Dan, can you please retest this on latest Firefox release and latest Nightly build (https://nightly.mozilla.org/) and report back the results ? Maybe it would be better also to use a new profile when doing this to exclude any custom settings that might interfere.


Thanks,
Paul

Comment 10

[Dan Callahan [:callahad]]

I haven't seen, heard of, or been able to repro this in a while.

Resolving as Works For Me.

Comment 11

[Carey]

I'm new to these forums. Forgive my noobness.

I'm seeing this corrupt localStorage and it's driving me crazy. I can't use feedly half the time on this one computer (my work computer). Restarting Firefox fixes the problem temporarily, but then it comes back. This is what I'm seeing in my console:

failed to inline entry Exception { message: "", result: 2152857611, name: "NS_ERROR_FILE_CORRUPTED", filename: "https://s3.feedly.com/web/30.0.1136…", lineNumber: 22, columnNumber: 0, data: null, stack: "[352]</</m.startReadTime@https://s3…" }

The item won't render, it's empty. If I try to reload feedly in a new tab, the entire tab is empty.

Is there a workaround? How to do clear/fix the localStorage?

Comment 12

[Andrew Sutherland [:asuth] (he/him)]

(In reply to Carey from comment #11)
> Is there a workaround? How to do clear/fix the localStorage?

I'm hoping you've addressed this problem, but for posterity:

The answer is that localStorage data is stored in the "webappsstore.sqlite" database in your profile directory.  If you delete it while Firefox is not running, you it will be re-created from scratch at startup.

Using about:support's profile "referesh" mechanism should likely accomplish a similar goal, assuming it doesn't copy the localstorage database into the new profile.

I think bug 1341070 will track this problem going forward.

Comment 13

[Dominique Quatravaux]

Attachment: bug1017066.tgz

I'm not entirely sure that this bug is fixed.

Per request of Luca Grego I am uploading the storage for my copy of the Simple Tab Groups plugin of his, that got corrupted during my recent upgrade to Firefox 66.0.2 (Mac OS X Mojave version 10.14.4 (18E226)).

Steps to reproduce the issue I am having:

1. Download and build Simple Tab Groups from source (although I suspect any add-on would cause the same problem)
2. Navigate to about:debugging and enable it if needed
3. Load the built addon/dist/background.js using the Load Temporary Add-on button and take note of its UUID
4. Open a terminal, cd to your profile directory, untar the attachment into an EXTRACTED subdirectory and cd back to your profile directory
5. rsync the EXTRACTED data over that of the temporary add-on with a command likenewuuid=f2ae7be4-3368-0d40-a655-bc8e6fcff78e; rsync -av EXTRACTED/storage/default/moz-extension+++d5b1612f-bb2d-cf46-9278-eb78a95372e0\^userContextId=4294967295/idb storage/default/moz-extension+++${newuuid}\^userContextId=4294967295/; rsync -av EXTRACTED/storage/default/moz-extension+++d5b1612f-bb2d-cf46-9278-eb78a95372e0/idb storage/default/moz-extension+++${newuuid}/
6. Back to the about:debugging page in Firefox, deactivate and reactivate the temporary add-on.

Expected result: An additional Simple Tab Groups icon shows up in the tab bar.

Actual result: An exception about it not being IndexedDB's fault pops up.

Additional steps to confirm that the problem is with storage.local and (presumably) not IndexedDB itself:

1. Run sqlite3 on every *.sqlite file in the attached archive, and at the prompt, run PRAGMA integrity_check; to rule out an sqlite corruption issue
2. From the about:debugging Firefox tab, clic Debug to start a debugger instance; click OK if prompted
3. From the JS console of said debugger instance, evaluate browser.storage.local.get(null).then(console.log)

Expected result: a dump of the storage.local state for this add-on
Actual result: crashes with the same message as before.

As correctly surmised in #944918, one cannot backtrack out of that situation by using browser.storage.local alone, and indeed browser.storage.local.clear() does not help.

Comment 14

[Luca Greco [:rpl] [:luca] [:lgreco]]

(In reply to Dominique Quatravaux from comment #13)

Created attachment 9055169 [details]
bug1017066.tgz

I'm not entirely sure that this bug is fixed.

This bug was related to localStorage/sessionStorage WebAPIs and not to the storage.local WebExtensions API.

Comment 15

[Luca Greco [:rpl] [:luca] [:lgreco]]

Comment on attachment 9055169 [details]
bug1017066.tgz

Marking as obsolete, the attachment is unrelated to this bug.

Comment 16

[Dominique Quatravaux]

(In reply to Luca Greco [:rpl] from comment #14)

(In reply to Dominique Quatravaux from comment #13)

Created attachment 9055169 [details]
bug1017066.tgz

I'm not entirely sure that this bug is fixed.

This bug was related to localStorage/sessionStorage WebAPIs and not to the storage.local WebExtensions API.

I see, my bad. Thanks for the clarification and for all the work and support!