Last modified: 2014-10-20 19:44:58 UTC
In some cases, MediaWikiModuleStore can be quite large (over 1 MB). This can lead to local storage becoming full and causing random problems like bug 64716. According to https://support.mozilla.org/en-US/questions/963825 Firefox shares local storage space across all hosts on a single domain name, so this may be especially problematic for Firefox. In theory, this shouldn't be an issue since people should always have some sort of fall-back behavior if there are problems with local storage, but in the interests of defensive programming, perhaps we should put a cap on the maximum size of MediaWikiModuleStore.
Any thoughts on this? This bug makes using Wikipedia very annoying for me. Surely I can't be the only person that cares about this.
(In reply to Ryan Kaldari from comment #1) > Any thoughts on this? This bug makes using Wikipedia very annoying for me. > Surely I can't be the only person that cares about this. This document explains how to clear localStorage: https://developer.mozilla.org/en-US/docs/Web/Guide/API/DOM/Storage#Storage_location_and_clearing_the_data You can also up the quota via about:config. Search for "dom.storage.default_quota" option. Its value is in kilobytes. I'm not suggesting that these are adequate resolutions for this bug -- they're just workarounds. I want to try something like what DJ is proposing in <https://bugzilla.wikimedia.org/show_bug.cgi?id=65364#c3>.
*** Bug 65364 has been marked as a duplicate of this bug. ***
Raising priority as this will likely become increasingly more problematic as wikis and extensions register more modules and users enable more features. mw.loader.store falls back to fetching from the server. However other features that actually use localStorage in a more visible way will lose data in a much worse way (e.g. users unable to store drafts, or a "hide" button not being remembered etc.)
(In reply to Krinkle from comment #4) > mw.loader.store falls back to fetching from the server. However other > features that actually use localStorage in a more visible way will lose data > in a much worse way (e.g. users unable to store drafts, or a "hide" button > not being remembered etc.) Yep, as you can see from bug 65566 (thanks for marking that as a see also), we've already had to switch to cookies for a feature due to this issue.
Ori: Any thoughts on this? It's still a significant problem, especially for Firefox users.
Ori: Could you reply to comment 6 please if you have some ideas?
What about this approach? 1. Before saving a module to localStorage try to save a string of 20 KB* there. 2. If this fails, don't save the module in localStorage. 3. If it succeeds, try to save the module. 4. Whether or not putting the module in localStorage succeeds, remove the string from step 1. This will make sure that the modules never will occupy the last 20 KB* of localStorage. *) 20 KB is just the first number that came to my mind. Feel free to replace it with any other reasonable number. I have several user scripts that make use of localStorage, they take up 3 KB, but I know users who use them more heavily than me, they probably end up at about 10 KB or more.
Michael M.: That sounds like a good idea, but doesn't solve the underlying issue of this bug (that mw.loader.store takes up too much of localStorage).
Filed an upstream bug against Firefox at https://bugzilla.mozilla.org/show_bug.cgi?id=1064466
