Closed Bug 1453699 Opened 6 years ago Closed 2 years ago

New items in LocalStorage are only accessible by tabs/windows that are open when the value was set in session-only mode

Categories

(Core :: Storage: localStorage & sessionStorage, defect, P3)

Product:
Core
Component:
Storage: localStorage & sessionStorage
Version:
59 Branch
Type:
defect

Tracking

()

Status:
RESOLVED WORKSFORME

People

(Reporter: mike.borman, Unassigned)

References

Details

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/64.0.3282.167 Safari/537.36

Steps to reproduce:

* open https://hacks.mozilla.org/2009/06/localstorage/ (viewA)
* enter text in the <textarea>
* open a new tab (or window) to the same url (https://hacks.mozilla.org/2009/06/localstorage/) (viewB)

to further explore the issue...
* return to viewA
* edit the text in the <textarea>
* reload viewB
* now localStorage value is available





Actual results:

The value stored in localStorage by viewA is not available to ViewB. Editing the text in viewA while viewB is still open gives viewB the expected access to the localStorage value




Expected results:

localStorage values should be available to new tabs and windows
Under "steps to reproduce" I should have added a 4th bullet...
* localStorage value does _not_ populate the <textarea> in viewB
Component: Untriaged → DOM
Product: Firefox → Core
Jan, could you take a look a this? Thanks.
Flags: needinfo?(jvarga)
Priority: -- → P3
I can't reproduce it.
Mike, do you still see it ?
Flags: needinfo?(jvarga)
Yes. I can still reproduce the issue as described. 

I do not have any add-ons or extensions.  Just a vanilla install of FF v61.0

Any settings I should check?

For completeness sake... here is a slightly more detailed description of the steps I am walking through.

* Starting with zero browser windows open.
* open https://hacks.mozilla.org/2009/06/localstorage/ (viewA)
* enter text in the <textarea>
* press [TAB] so text area loses focus
* open a new tab (or window) to the same url (https://hacks.mozilla.org/2009/06/localstorage/) (viewB)
* scroll down to the text area in viewB.
* The text entered in ViewA _should_ be visible in viewB, but it is not. ViewB shows the placeholder text.
Flags: needinfo?(jvarga)
Local storage seems to be acting like SessionStorage, meaning changes saved to local storage do not persist across browser restarts. Additionally, local storage is only affecting the Current Tab. Other tabs do not see the localstorage properly, and each tab has its own independent local storage. Affects FireFox 62.0 64-bit on arch linux, tested with addons disabled.

Expected results:
All tabs use same LocalStorage for the same site.
Changes made to local storage affects other tabs local storage immediately, changes become visible on page after reloading.
On browser restart, local storage is properly loaded for each site.
Different methods of setting the same value to the same storage type do not change the results.


Actual Results:
All tabs start with nothing in local storage.
Any changes to local storage are only seen by the current tab's local storage, AND tabs with the SAME HISTORY (middle click on browser back/forward button), not other tabs or new tabs (via browser new tab button or middle click on a link).
On browser restart, local storage is empty for each site.
localStorage.setItem('key',value) does not affect other tabs localStorage, but modifications done in Storage-Inspector affect all tabs.


Steps to Reproduce:
1) Go to any site (eg. http://example.com/) in two different tabs
2) Open storage Inspector (Shift + F9) > LocalStorage > CurrentSite (eg. http://example.com) on both tabs
3) Set a LocalStorage value via the JavaScript console (eg. localStorage.setItem("a",1) ) on one tab.
4) Notice that the other tab does not have the item in LocalStorage. Refreshing does not change the result
5) Modify LocalStorage via the Storage Inspector (eg.1 Change key "a" to "b". eg.2 Push the Add Item (+) button )
6) Notice that both tabs were properly affected.

Scope TODO:
Untested, assuming it affects all sites.
Not tested on Mac/Windows.
Correction, same history doesn't actually cause it to remember. I just got the tabs mixed up in my original tests. Forgot to delete that line after I did more thorough tests with addons disabled.
Retested in new profile, update for minimum changes necessary to reproduce.

Related: https://bugzilla.mozilla.org/show_bug.cgi?id=896742
Possibly the cause of https://bugzilla.mozilla.org/show_bug.cgi?id=1178209

Steps to reproduce (update):

1) Set 'Preferences > Privacy & Security > Cookies and Site Data > Keep until: "Firefox is closed"' (via about:preferences#privacy )
2) Go to any site (eg. http://example.com/) in two different tabs
3) Open storage Inspector (Shift + F9) > LocalStorage > CurrentSite (eg. http://example.com) on both tabs
4) Set a LocalStorage value via the JavaScript console (eg. localStorage.setItem("a",1) ) on one tab.
5) Notice that the other tab does not have the item in LocalStorage. Refreshing does not change the result
6) Modify LocalStorage via the Storage Inspector (eg.1 Change key "a" to "b". eg.2 Push the Add Item (+) button )
7) Notice that both tabs were properly affected.
(In reply to brandonrbeck101 from comment #7)
> 1) Set 'Preferences > Privacy & Security > Cookies and Site Data > Keep
> until: "Firefox is closed"' (via about:preferences#privacy )

Thank you for the exact STR!

This is the problem.  This enables session storage mode which does not persist to disk at all under the current implementation.  (At the time it was implemented, the thought was that for privacy reasons, data in this mode should never touch disk.  I believe you'll see similar issues in pre-e10s Firefox releases if you close all of the tabs to the site and wait 20 seconds and then open a new one.  There is some bfcache interaction, so it's necessary that all tabs involved in the origin were closed.)

This should be resolved with the landing of next generation LocalStorage in bug 1286798 which has a more elegant e10s implementation, although as reviewer I will need to double-check my understanding of how the implementation deals with this.
Summary: New items in LocalStorage are only accessible by tabs/windows that are open when the value was set. → New items in LocalStorage are only accessible by tabs/windows that are open when the value was set in session-only and Private Browsing mode
I am running Nightly 66.0a1 (2018-12-20) (64-bit). The bug https://bugzilla.mozilla.org/show_bug.cgi?id=1286798 appears to have been pushed in on v65, so I thought I should retest. This issue still remains. Furthermore, it seems a bit more complex than I originally thought (or possibly has become more complex)

First, the setting path has changed.
Old setting path: 'Preferences > Privacy & Security > Cookies and Site Data > Keep until: "Firefox is closed"'
New setting path: 'Preferences > Privacy & Security > Cookies and Site Data > Delete cookies and site data when Nightly is closed' (via about:preferences#privacy )

To make this easier to read/write, I will hereby refer to this setting as Setting "DSD" (for Delete Site Data). 
Enable DSD will refer to the act of checking the setting
Disable DSD will refer to the act of unchecking the setting

Steps to reproduce:
0) Open a new Firefox profile.
1) Enable DSD
2) Open https://hacks.mozilla.org/2009/06/localstorage/ (viewA)
3) Enter text in the <textarea>
4) Do any of the following
4a) Open https://hacks.mozilla.org/2009/06/localstorage/ in another tab ()
4b) Close the tab and reopen it
4c) Go back in history to a different site and then go forwards back to it
4d) Visit any other site and then revisit it by any means other than going back in history.
5) Notice the text was not loaded.

Other things to note:
* LocalStorage settings from back when DSD was disabled load as per normal. But LocalStorage changes from after enabling DSD are not loaded.
* LocalStorage changes when DSD is enabled affect all opened tabs on the same page.

What this means:
1) New tabs load LocalStorage that was saved while DSD was disabled
2) New tabs DO NOT load LocalStorage that was saved when DSD was enabled.
3) When DSD is enabled, new LocalStorage saves in a session storage like manner, with each tab owning its own LocalStorage.

4) When DSD is enabled, new LocalStorage saves to all tabs CURRENTLY on the same page.


To test this:
1) Disable DSD
2) Open https://hacks.mozilla.org/2009/06/localstorage/ in a new tab (tabA)
3) Enter text in the <textarea>
4) Enable DSD
5) Change text in the <textarea>
6) Open https://hacks.mozilla.org/2009/06/localstorage/ in a new tab (tabB)
7) Notice text from step 3 is there but changes from step 5 are missing.(evidence for #1 and #2)
8) In tabA, go to another site or page (example.com)
9) In tabA, revisit https://hacks.mozilla.org/2009/06/localstorage/ by typing it in the address bar (do not use back button as back doesn't utilize LocalStorage)
10) Notice text from step 5 is still there (evidence for #3)
11) In tabA, Change text in the <textarea>.
12) Refresh tabB.
13) In tabB, Notice the text from step 11 is there. (Combined with what we learned in step 7, this is evidence for #4)


Given all this information, I conclude that localstorage is being saved in a different location when DSD is enabled. After all, if it were being saved in the same location, Step 7 world have failed since Step 5 would have overwritten the changes. If we were not saving at all, step 10 and 13 would fail.

I additionally tested #4 by:

1) Opening tab A and B
2) Visiting the site and making changes on tabA
3) Visiting the site on the already opened tabB. (changes from step 2 will not load)

1) Visiting the site on tab A and B.
2) Going to another site on tab B.
3) Making changes on tab A.
4) Revisiting the site on tab B. (changes from step 3 will not load)
Did you test with dom.storage.next_gen set to true or false ?
Flags: needinfo?(jvarga)
Should have looked if there was a config flag mentioned.
Retested with next_gen enabled and everything seems to be working as expected!

All of the mentioned quarks are gone. Also tested custom clear history settings, succeeded to both keep and delete website data as expected :D

Problem solved for me!
(Perhaps I should start closing my browser and tabs again)
I'm glad to hear that it's fixed.

I was afraid to ask about the pref setting, since you must have put a lot of effort into writing such detailed comment.

Anyway, we landed a patch today that makes LSNG to be default implementation on Nightly, so next Nightly build will have that by default.
Component: DOM → DOM: Core & HTML
Component: DOM: Core & HTML → DOM: Web Storage

Bug is still present for me using Firefox 71.0.

Not being able to share localStorage data between tabs when this setting is enabled is really problematic. A lot of Single Page Applications use localStorage to persist authentication data (access/refresh tokens) and preferences, so when you open new tabs by middle clicking links, you lose all context and need to re authenticate, rendering tab-based browsing unusable on the website.

(In reply to Maxime Rossini from comment #16)

Bug is still present for me using Firefox 71.0.

Not being able to share localStorage data between tabs when this setting is enabled is really problematic. A lot of Single Page Applications use localStorage to persist authentication data (access/refresh tokens) and preferences, so when you open new tabs by middle clicking links, you lose all context and need to re authenticate, rendering tab-based browsing unusable on the website.

Hi Maxime, we are still stabilizing LSNG (which solves this issue) such that it is not on by default in releases (only in beta and nightly). You can switch it on using the pref dom.storage.next_gen set to true.

Yep, this is definitely a valid solution for me, but not for the users of my application :)
Is there any expected release version for the fix to become automatically propagated to normal users?

This issue comes up occasionally on SUMO. The workaround for the end user is to create a site-specific "Allow" cookie permission, for example, via the Page Info dialog. (Call up Page Info using Ctrl+i or on Mac Command+i, click the Permissions icon, scroll down to the Set Cookie row, uncheck the box for Use default, click Allow, then you can close the dialog.)

For example, in recent months, when a user opened a message in a new window on the OWA platform for Office 365/Outlook.com/Live/Hotmail, it was blank or said "you can close this window now." Sample threads:

I'm here now because today a user reported repeated location permission nags in new tabs on a site with session-only cookies. https://support.mozilla.org/questions/1294490 Same issue: they put their flag in local storage.

Fingers crossed LSNG is done soon!

Hi Maxime, we are still stabilizing LSNG (which solves this issue) such that it is not on by default in releases (only in beta and nightly). You can switch it on using the pref dom.storage.next_gen set to true.

IS this ISSUE FIXED ? We are still seeing this issue in some machines.

(In reply to Maxime Rossini from comment #16)

Bug is still present for me using Firefox 71.0.

Not being able to share localStorage data between tabs when this setting is enabled is really problematic. A lot of Single Page Applications use localStorage to persist authentication data (access/refresh tokens) and preferences, so when you open new tabs by middle clicking links, you lose all context and need to re authenticate, rendering tab-based browsing unusable on the website.

Still present for me in FF 84. SPA problem above is exactly my problem, new tabs have empty localStorage, and a reauth-sequence in a new tab, even makes the FIRST TAB log out when the first tab tries to fetch an auth token from LS!

Hello,
the bug is still present for me (using Firefox 86.0).

Is there any news on that? Some of my clients are complaining that they can't open a new tab without signing in with my current implementation - which depends heavily on localStorage for several reasons.

The private browsing situation described here was fixed by bug 1669437 in Firefox 84 which moved the legacy LocalStorage implementation to retain data in memory of the parent process. Unfortunately, the approach used for private browsing cannot trivially be reused for both complexity reasons and concerns about unbounded memory usage growth in the parent process. (Which is not to say there aren't concerns about unbounded memory use in the parent process for private browsing, but the ability to clear private browsing storage when its last window are closed while retaining the normal browsing windows helps bound the lifetime of the data in non-permanent-private-browsing scenarios.)

Bug 1681493 tracks obsoleting the current session-only cookie behavior mode to instead use the sanitizing mechanisms that is used by LocalStorage NG. Practically speaking I think that may depend on either moving to LSNG or having Legacy LS expose a mechanism for enumerating its stored principals in https://searchfox.org/mozilla-central/source/toolkit/components/cleardata/PrincipalsCollector.jsm. This information is already known via mOriginsHavingData. In the case where legacy LS is expanded, the session dataset could be removed. This would slightly change the experience of a user who toggles session-only browsing for an origin multiple times during a single browsing session, but arguably the behavior of session-only cookies for LocalStorage are a bit nonsensical. (Specifically, session-only LocalStorage loads the on-disk state of LocalStorage for the origin last saved before the user transitioned to session-only mode for the origin.)

See Also: → 1681493
Summary: New items in LocalStorage are only accessible by tabs/windows that are open when the value was set in session-only and Private Browsing mode → New items in LocalStorage are only accessible by tabs/windows that are open when the value was set in session-only mode

This should be fixed in FF 89. Bug 1703310 introduced auto-enabling of LSNG when network.cookie.lifetimePolicy=2.

Severity: normal → S3

The severity field for this bug is relatively low, S3. However, the bug has 3 duplicates.
:jjalkanen, could you consider increasing the bug severity?

For more information, please visit auto_nag documentation.

Flags: needinfo?(jjalkanen)

(In reply to Jan Varga [:janv] from comment #25)

This should be fixed in FF 89. Bug 1703310 introduced auto-enabling of LSNG when network.cookie.lifetimePolicy=2.

Closing as LSNG is now always enabled. Feel free to file a new bug if you encounter still issues and thanks for your support.

Status: UNCONFIRMED → RESOLVED
Closed: 2 years ago
Flags: needinfo?(jjalkanen)
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.