Page MenuHomePhabricator

Reply tool losing unsaved content on reload for new comment
Closed, ResolvedPublicBUG REPORT

Description

Steps to replicate the issue (include links if applicable):

Edit a talk page on enwiki using the reply tool. While you are composing your reply, in another window, reply to the same thread and save your comment. In the first window, you'll get a "Show 1 new comment" alert popup

Screen Shot 2023-02-09 at 10.29.52 AM.png (2×2 px, 1 MB)
. Click the button. The page reloads, you get a popup that tells you that your unsaved content was restored, but the edit box is empty
Screen Shot 2023-02-09 at 10.30.06 AM.png (2×2 px, 1 MB)

This just started happening this morning.

MacOS Monterey 12.6.1 (21G217)
Chrome Version 109.0.5414.119 (Official Build) (x86_64)

Event Timeline

I can't reproduce. Do you have localStorage disabled for some reason? Do you see an errors on the javascript console?

Interesting. Yes, I'm seeing javascript errors on page loads (even before I try to edit anything). It's not entirely reproducible, but they're all variations on:

DOMException: Failed to execute 'setItem' on 'Storage': Setting the value of 'MediaWikiModuleStore:enwiki' exceeded the quota.

Here's a few, while loading https://en.wikipedia.org/wiki/Wikipedia_talk:Did_you_know:

Uncaught DOMException: Failed to execute 'setItem' on 'Storage': Setting the value of 'ds-locked-user 狄の用務員' exceeded the quota.

Uncaught DOMException: Failed to execute 'setItem' on 'Storage': Setting the value of 'ds-locked-user MyCatIsAChonk' exceeded the quota.

Exception in store-localstorage-update:
DOMException: Failed to execute 'setItem' on 'Storage': Setting the value of 'MediaWikiModuleStore:enwiki' exceeded the quota.

When I go to my Sandbox, I just get the one:

Exception in store-localstorage-update:
load.php?lang=en&modules=startup&only=scripts&raw=1&skin=vector:1 DOMException: Failed to execute 'setItem' on 'Storage': Setting the value of 'MediaWikiModuleStore:enwiki' exceeded the quota.

There's some huge stack dumps that I've omitted; I can get those for you if they're useful.

exceeded the quota.

The browser is saying: "this website has used too much storage on the device"

There's some huge stack dumps that I've omitted; I can get those for you if they're useful.

That's what https://phabricator.wikimedia.org/paste/edit/form/45/ is for ;)

The ds-locked-user error is coming from: https://en.wikipedia.org/wiki/User:DaxServer/Mark-locked.js
That script is pretty broken, as it generates infinite keys that it will never clean, and it hasn't wrapped its usage localstorage in try/catch. I have left them a note asking to correct these significant problems.

Hi. I've disabled using localstorage for the time being. Sorry about the mess. I've indeed put an expiry of 1-3 days. I'm not sure why it's generating keys without expiry. I'll debug it when I get some time. Thanks!

Note also that we recently added timed expiry to the mediawiki.storage API, which wraps localStorage.

Not that we did account for this situation which is why we created the MemoryStorage wrapper (https://github.com/wikimedia/mediawiki-extensions-DiscussionTools/blob/9058467403d020f137997f121fae07346b08b505/modules/createMemoryStorage.js).

For the case described where the page isn't fully reloaded, the storage data should be mirrored to local memory and the recovery should still work, so there is something to investigate here...

I've tested by flooding my localStorage locally to point where autosave starts failing silently, and the memory storage wrapper appears to be working fine. Showing new comments preserves your draft message via in-memory storage.

I can only suspect the uncaught exceptions where the cause here in which case I suggest we close this task as resolved.

So… have we figured out what is happening here, or not? I am a little confused by the discussion so far.

The immediate cause is definitely a change in DiscussionTools: in https://gerrit.wikimedia.org/r/c/mediawiki/extensions/DiscussionTools/+/829078 we've made a change to use localStorage instead of sessionStorage, to fix some scenarios where autosaving did not work (T218663). This means we're now affected by different quotas.

But as @Esanders says above, when reloading the page to show the new comments, we have a fallback that just stores data in memory, which should work even when localStorage is unavailable. Is that broken?

We've also noticed a different problems with the mechanism to show new comments (T329523), and it sounds related at a glance, but it is failing (for me) in a very different way than the symptoms here, so I am not sure after all if it's the same problem.

Even if @DaxServer's script caused the issue in reply tool (I'm not sure if that's the case), commenting out the code that stores data doesn't cause existing data to be deleted, so I don't think that will have an effect for the users who are already affected (but may avoid future problems). You'd need to add code to delete the existing data too.

So… have we figured out what is happening here, or not? I am a little confused by the discussion so far.

Meta: I'm moving this ticket to the current workboard so that we can decide what – if anything – the Editing Team might need to do to prevent this issue from continuing to happen/happening to more people.

I've backported the fix for T329523, in case it is really the same issue. @RoySmith Can you check if you still experience this problem?

I haven't seen it again after I reported the original incident. But I'll let you know if I see it again.

I just saw it happen again on https://en.wikipedia.org/wiki/Wikipedia_talk:Did_you_know#Prep_7:_Chicago_station_(CTA_Logan_Square_branch)_(nom)

Javascript console has:

Exception in store-localstorage-update:
DOMException: Failed to execute 'setItem' on 'Storage': Setting the value of
'MediaWikiModuleStore:enwiki' exceeded the quota.

at flushWrites (https://en.wikipedia.org/w/load.php?lang=en&modules=startup&only=scripts&raw=1&skin=vector:19:440)

But as @Esanders says above, when reloading the page to show the new comments, we have a fallback that just stores data in memory, which should work even when localStorage is unavailable. Is that broken?

Per my comment above, I couldn't reproduce this failure by just flooding localStorage to the point that it becomes unavailable.

I'm seeing this again. I again have in my console:

Exception in store-localstorage-update:
DOMException: Failed to execute 'setItem' on 'Storage': Setting the value of 'MediaWikiModuleStore:enwiki' exceeded the quota.
    at flushWrites (https://en.wikipedia.org/w/load.php?lang=en&modules=startup&only=scripts&raw=1&skin=vector:19:440)

Looking in Application/Storage/Local Storage, I can indeed see a large number of db-locked-user entries. I'm not sure how many, but it must be many 100's (the console is *really* slow to update showing the list). Assuming the "expiry" values are unix timestamps in msec, they all look to be dates in the past. For example:

>>> ctime(1664806650523/1000)
'Mon Oct  3 10:17:30 2022'

If you give me some ideas what to look for, I'll be happy to dig some more the next time it happens.

Screen Shot 2023-02-18 at 11.46.58 AM.png (2×2 px, 1 MB)

You can execute localStorage.clear() from your console and that will throw away all the data ever collected, and allow you to start with a fresh empty store. U might also loose some other preferences and state (collapsed items in the editor etc) etc, but its really the only way to clear localstorage once it filled up.

@TheDJ before I do that, is there any value to the people trying to debug this to my leaving things they way they are now, since it seems I can reproduce it and nobody else can?

@RoySmith It could be useful if it's not a big inconvenience.

@RoySmith Can you open the Chrome developer tools on Wikipedia again, share another screenshot of the same interface after typing "reply/" into the "Filter" field at the top? (Please review it before uploading, to make sure you're not sharing anything you didn't mean to, as the value includes the entire undo/redo history of anything you typed in the autosaved reply.)

The reply tool stores autosave data using several storage keys. I wonder if the problems occur when the storage is almost but not completely full, so that some of our keys are stored while others are not.

I also wonder whether this bug report is somehow related: https://en.wikipedia.org/w/index.php?title=Wikipedia:Village_pump_(technical)&oldid=1140190699#"Reply"_on_talk_page_grayed_out

Hi. Sorry it took so long to get back to you. On https://en.wikipedia.org/wiki/Wikipedia_talk:Did_you_know, on the page I've got:

Screen Shot 2023-03-01 at 3.14.55 PM.png (2×2 px, 1 MB)

and in the dev tools window (note, the value field is empty):

Screen Shot 2023-03-01 at 3.16.14 PM.png (2×2 px, 777 KB)

If I do the same thing in an incognito window:

Screen Shot 2023-03-01 at 3.21.24 PM.png (2×3 px, 1 MB)

Change 929806 had a related patch set uploaded (by Bartosz Dziewoński; author: Bartosz Dziewoński):

[mediawiki/extensions/DiscussionTools@master] Redo wrapper for localStorage integration

https://gerrit.wikimedia.org/r/929806

Change 929806 merged by jenkins-bot:

[mediawiki/extensions/DiscussionTools@master] Redo wrapper for localStorage integration

https://gerrit.wikimedia.org/r/929806