content icon indicating copy to clipboard operation
content copied to clipboard

Storage.setItem is a synchronous function, but the browser's implementation of committing changes to storage may be asynchronous

Open davidbroyles opened this issue 1 year ago • 3 comments

MDN URL

https://developer.mozilla.org/en-US/docs/Web/API/Web_Storage_API

What specific section or headline is this issue about?

setItem generally throughout this section

What information was incorrect, unhelpful, or incomplete?

There's no mention of potential loss of data if something is written via Storage.setItem(...) and immediately followed by e.g. window.location.href = '/'

What did you expect to see?

I don't know if this page, or setItem's, or sessionStorage & localStorage is the most appropriate place for a note, but I've run into a lot of debugging situations where the browser's implementation of committing the data occasionally fails to complete before a redirect, resulting in a loss of data. While the JS function is itself synchronous, a lot of browser implementations appear to have asynchronous implementations with respect to nonvolatile storage across pageloads, creating a race condition. Adding a note to give a brief pause before redirects/unloads could save a lot of devs heartache. I'm not convinced that a getItem check would suffice, since it may be reading from the same volatile cache that setItem is initially writing to.

Do you have any supporting links, references, or citations?

No response

Do you have anything more you want to share?

No response

MDN metadata

Page report details
  • Folder: en-us/web/api/web_storage_api
  • MDN URL: https://developer.mozilla.org/en-US/docs/Web/API/Web_Storage_API
  • GitHub URL: https://github.com/mdn/content/blob/main/files/en-us/web/api/web_storage_api/index.md
  • Last commit: https://github.com/mdn/content/commit/44c4ec928281dc2d7c5ea42b7d2c74a2013f16ac
  • Document last modified: 2024-07-26T15:41:23.000Z

davidbroyles avatar Oct 10 '24 15:10 davidbroyles

There's no mention of potential loss of data if something is written via Storage.setItem(...) and immediately followed by e.g. window.href = '/'

I think you are saying location.href = '/'?

And I try to make some small test, but can not figure out if the issue would happen.

skyclouds2001 avatar Oct 10 '24 16:10 skyclouds2001

Yes, sorry! I updated the original comment with window.location.href. I'm not sure if it has to do with larger/complex scripts having more overhead and making late writes more likely for sessionStorage, but I'm also having trouble replicating it with a smaller test, e.g.

console.log('retrieved value: '+sessionStorage.getItem('test'));
var val = Date.now();
console.log('written value: '+val);
sessionStorage.setItem('test', val);
window.location.href = '?'+val;

The error has occurred for me across multiple projects using different frameworks, though. The fix was always the same, but I didn't know what was causing it. When I asked chatGPT, it said

sessionStorage operations are synchronous, but if you write to sessionStorage immediately before a page redirect, the browser may not have enough time to properly commit the data to storage before the page unloads. This can lead to scenarios where the data is not available on the next page load.

Sorry if opening this Issue was premature, we can close it if it's not sufficiently vetted for documentation. I've just had this problem multiple times across very different environments, and the fix was always the same.

davidbroyles avatar Oct 10 '24 16:10 davidbroyles

I'm not sure if there's anything actionable if we can't isolate a demo and confirm that it's working as intended and not a browser bug.

Josh-Cena avatar Oct 10 '24 22:10 Josh-Cena

I'm closing it due to the lack of information available here. Please let us know if you find more.

Josh-Cena avatar Feb 09 '25 05:02 Josh-Cena

The error has occurred for me across multiple projects using different frameworks, though. The fix was always the same, but I didn't know what was causing it. When I asked chatGPT, it said

may I ask, what you fix was? I have encountered the exact same issue an tried to mitigate the risk of this happening by redirecting with a 250ms timeout. However, on slow hardware, the problem still occurs occasionally.

olafkeding avatar Feb 10 '25 08:02 olafkeding

My understanding is that this is only related with sessionStorage?

skyclouds2001 avatar Feb 10 '25 15:02 skyclouds2001

My understanding is that this is only related with sessionStorage?

I had this problem with sessionStorage. This thread on StackOverflow suggests, that the same issues are faced with localStorage: https://stackoverflow.com/questions/20231163/is-html5-localstorage-asynchronous

olafkeding avatar Feb 10 '25 15:02 olafkeding