Identify cases of data corruption at runtime
Background / User story
We currently identify cases of data corruption as follows:
- After loading:
- If no filter lists exist (incl. custom filters)
- Previous version is set but stat file doesn't exist
- After installing or after major update (i.e. no problem found after loading):
- If setting "last_updates_page_displayed" preference fails
This means that for any cases where the data corruption has been introduced after installation, we likely don't detect it for any sessions other than the ones immediately after a major update. Therefore we should additionally provide on-demand runtime checks that we could use to avoid data corruption-related problems (e.g. to improve on #829 (closed)).
What to change
- Design: N/A
- Research: N/A
- Spec: N/A
- Legal: https://jira.eyeo.com/browse/ABPUI-47
- Provide function that checks whether reading and writing preferences from extension storage works.
- We may need to randomize the preference value we're reading/writing and maybe even the preference key, in order to minimize the potential for running into in-memory browser caches.
- Use function to determine whether notifications should be shown (see #829 (closed)).
Hints for testers
Until eyeo/adblockplus/adblockpluschrome#201 (closed) is done, we're not going to detect any additional cases of data corruption yet, which could trigger the data corruption to be shown outside of the first-run/update scenario.
However, you can simulate a data corruption being present at any time anyway, with a small modification to the code (see webext#244).
Hints for translators