I think the issues in T329299 are caused by partially autosaved
comments. We store data in multiple localStorage keys, and if some of
them are stored but others are not (due to exceeding storage quota),
our code can't handle the inconsistent state.
We already have a wrapper around localStorage that tries to cover up
these issues. Change it so that all values specific to an instance of
a reply tool are stored under one localStorage key. This ensures that
all updates consistently succeed or fail, with no partially stored
state.
One of the reasons we haven't done this is because this requires the
whole data to be serialized to JSON every time, but our experience
with VE change 4355d697aa shows that this is fast enough.
Extra changes:
* Remove storagePrefix, now redundant
* Remove use of createConflictableStorage, now redundant
* Prefix the key with 'mw' as advised by mw.storage documentation
* Use ES6 syntax for the new code (just for fun)
* Use consistent expiry (T339042)
Bug: T329299
Change-Id: I347115f7187fd7d6afd9c6f368441e262154233b
We switched to our memory-wrapped store everywhere outside the
VE surface, but not in the VE surface itself.
Change the way we construct MemoryStorage objects so that they can
be constructed from a specific mw.SafeStorage instance.
Ensure MemoryStorage's cache is populated with initial storage object
data, and that the cache is copied over when we create derivative
objectes.
Bug: T310438
Change-Id: I652428f114dc5169195887cb8ca719ae196bb76f
The parent constructor may trigger read/writes in the future
so this.data should always exist as early as possible.
Change-Id: I79a795a26c4ce1381d2a0b15329f7df1d6ab77ca
