Warn in DevTools before clearing localStorage

[1j01]

I tried out the lighthouse Chrome extension and it wiped out my IndexedDB etc. without any indication that it was going to do so. I can see why it would, but this deleted a lot of data that could have been important. So it should mention that.

[michaeljonsampson]

Just ran into this. A warning would be a good addition.

[paulirish]

@michaeljonsampson curious.. which part of storage was cleared that you were surprised by? We actually keep cookies alone, but it's possible you were using localStorage for similar purposes. :/

[michaeljonsampson]

IndexedDB data was deleted.

[paulirish]

Let's stop clearing idb and localstorage. Leave it to the user to clear that themselves.

[brendankenny]

If we do this, I think we should detect if the site has something in idb or localstorage and issue a top-level warning that it should be manually cleared if it might impact loading time. e.g. predownloaded or precomputed assets (like compiled wasm modules).

It would be easy to forget to clear between lighthouse runs and have no idea why your score changed so much, especially if the caching is done by a library and without code written by the developer themselves.

[wardpeet]

The extension will be replaced with a different version by #9193

Devtools has a checkbox to not clear storage:

Whenever we fix #2599 we can integrate multiple checkboxes in devtools but as of now, This issue can be tracked by #2599 as well.

[Aditya94A]

It seems like the checkbox was removed. Is there some other way to do this now?

[patrickhulce]

@AdityaAnand1 it's behind the "Settings" cog in the top right now.

[1j01]

If it's hidden behind a cog, it's no longer signaling to user that it's going to clear storage.
"Generate report" sounds very additive and friendly, but it's a destructive action.

For context, in my case I'm storing documents for a drawing program in IndexedDB via localforage.
Luckily I had saved most of the documents I wanted to keep, but this was very surprising.
I'm developing this app with an ethos of "don't destroy data by default" (and more generally, "fearless exploration"), so I'm saving undo/redo history, as a tree, with the document. I care a lot about this stuff.

[patrickhulce]

Yeah a fair point @1j01! Feel free to star the Chromium issue to add a warning (https://bugs.chromium.org/p/chromium/issues/detail?id=806488)

[paulirish]

proposal:

• new "Clear caches" checkbox which does sw, cache storage, appcache, but NOT localstorage, idb, and websql
• we look at the localstorage/idb/websql and if they have stuff in there (for that origin), then we tell them they should do incognito, etc.

[paulirish]

@connorjclark can you capture here what you were proposing for this?

[connorjclark]

just this

we look at the localstorage/idb/websql and if they have stuff in there (for that origin), then we tell them they should do incognito, etc.

we should do this for other things too. a list of warnings below "Generate Report" sayings things like, FYI: We noticed local overrides, we noticed data in storage, we noticed blocked requests, just FYI in case this wasn't intentional.

[brendankenny]

Reading this DevTools use of Chrome Profiles doc, can we avoid having to make these assumptions and reduce magic if we open an incognito-ish new window when "Clear storage" is checked, and reuse the tab when it isn't checked?

Right now (from the doc) it looks like you can do Target.createBrowserContext to get an off the record BrowserContextID, then pass that into Target.createTarget to create the new window. From that doc it sounds like there is some work to be done to make it a really real ephemeral profile that the rest of Chrome will work with normally, but it seems like it would work once that's done?

I assume this would be more straightforward to do in the DevTools side of things than in Lighthouse core, but I wonder if it would make anything in interoperation with chrome-launcher easier as well.

[mpkelly]

Please deselect "Clear storage" by default or at least show me a prompt that tells me you're going to wipe out my DB.

[adamraine]

@brendankenny looks like the ephemeral profiles idea was scrapped.

I think adding a warning is the best option for now.

[adamraine]

This is a basic solution I came up with. Currently checks for localstorage/idb/websql via Storage.getUsageAndQuota.

I'm temporarily using the "unauditable" error text. Looks like there are a couple ways we could display the warning:

• A warning list below the "Generate report" button: Similar to the picture. This would still be pretty obvious but not impossible to miss. Might be better for other warnings too @connorjclark
• An explicit confirmation prompt: This would be impossible to miss, not sure if it's the best way to display an error list.
• Combination of both: Detailed warning list with confirmation prompt that just says something like "There are some warnings, pls check before running"

I'm currently in favor of just the confirmation prompt for now but I'm willing to hear others' thoughts.

[connorjclark]

Combination of both

That would be interesting! But with an additional feature of "Never remind me again" (we could add it to the settings cog, I guess).

Other warnings we might want in this list:

• Local Overrides is on–Lighthouse will audit the page with your overrides
• Blocked Urls–Lighthouse will audit the page but some requests will be blocked
• more?

[kepta]

This is a pretty bad experience. I lost a lot of data by not knowing that running a lighthouse report will clear it. I took a backup of that data in one of my other website, but apparently I ran lighthouse on that too, so now I lost it forever.

[patrickhulce]

@adamraine has taken care of us here 🎉