1313422 - Clear orphaned WebExtension storage

Status: NEW

(WebExtensions :: Storage, defect, P5)

Description

[Tom S [:evilpie]]

Before bug 1213990 everything that is written to storage by an extension would just stay indefinitely. We are already shipping WebExtensions, so it's quite likely that people already have orphaned data from uninstalling WebExtensions before their browser version includes that patch.

Comment 1

[Nancy Grossman]

Yes, and before bug 1213990 you could reinstall an extension to clear a hangfire without losing your data. If there isn't already an extension that does this sort of thing then maybe it doesn't need to be done?

Comment 2

[Andrew Swan [:aswan]]

I don't know the term "hangfire".  However, see the note near the top of https://developer.mozilla.org/en-US/Add-ons/WebExtensions/API/storage/local about prefs that you can use if you really need to override that behavior.

Comment 3

[Nancy Grossman]

Thank you for the link, Andrew Swan; I've set my switches accordingly. I was responding as a consumer though and not as a developer. As a consumer I really must insist that you not delete my data without first asking permission or, better yet, offering to move it somewhere more accessible to me. Even though much of it is debris without the extension that created it, some of it is not.

Since you're going to detect and delete orphaned data to resolve this bug anyway, then why not give it a UI? Ask the users what they want to do, let it be run on demand from "Clear recent history" or from the "Add-ons Manager", and roll back bug 1213990? (I know, I'm sorry, you worked so **** it, but it was an awful decision.)

Comment 4

[Andrew Swan [:aswan]]

(In reply to Nancy Grossman from comment #3)
> Thank you for the link, Andrew Swan; I've set my switches accordingly. I was
> responding as a consumer though and not as a developer. As a consumer I
> really must insist that you not delete my data without first asking
> permission or, better yet, offering to move it somewhere more accessible to
> me. Even though much of it is debris without the extension that created it,
> some of it is not.

Hm, I certainly don't think there's a reliable way for the browser to tell what extension-created data might be worth keeping and I don't think its much easier for users to tell in general.  The only real solution here is for extension developers to build in features that make it easy to save/export any important data that might be created from within an extension.  There are lots of ways to do this and we'll soon be landing browser.storage.sync which offer a very easy way to do it.  And for sophisticated users who really want to do this, we have the settings discussed previously.

> Since you're going to detect and delete orphaned data to resolve this bug
> anyway, then why not give it a UI?

Because "giv[ing] it a UI" is not a small task when you account for designing the UI/UX, implementing it across all the platforms we support, testing it, and maintaining all that resulting code.  Without a more compelling case that this would be useful for a significant number of users, doing that work isn't justified.

Maybe you could describe a specific scenario where you want this in more detail?  If you want to stop using an extension for a while then re-install it later and have your previous settings/state preserved, why not just disable the extension instead of uninstalling it?

Comment 5

[Nancy Grossman]

A specific scenario? My 'Stylish' stops working. My styles are listed, but they aren't applied. OK, maybe something got jammed in Stylish, so I uninstall it and re-install it. No joy. I restart Firefox - no joy. I go to the support site and find out I've disabled all the styles at once without realizing it. Silly me! I flip the 'enable all' switch - no joy. Wait, oh no, now all my styles are gone! Really gone! Deleted! (Stupid Firefox!)

That doesn't happen yet in Firefox because Firefox didn't delete add-on data before bug 1213990. (And why do it at all? Maybe you could describe a specific scenario where storage that is "safe" while an extension is present becomes a privacy risk after it is gone. Does it become a risk when the extension is disabled, or is it "safe" because the extension is still installed?) So it will be a surprise to current users. (yay?)

I don't know how many users that scenario represents. I'll guess more than there are GM users, fewer than there are ABP users. Certainly a lot more than there are sophisticated users. When good apps go bad, a surprising number of people do exactly what I've described - reinstall the app, then restart the browser, then ask for help. (cf. bug 1213990 comment 3)

The add-on is easily restored, the data is not, and accidents happen. That's why we have "Undo" buttons and "Trash" folders, and why no installer you've used in the last 20 years has taken your data on uninstall without asking. (Including Firefox's.) If you must delete the data automatically, then at least don't do it immediately. I'd prefer though that you let us choose.

The UI could be a single input, a checkbox ("Keep the data") next to 'Undo' in the add-ons manager on 'Remove', or an option in add-on manager's 'Tools' drop-down to sweep old extension data, or a checkbox in 'Clear Recent History' to do the same. I'm sorry if that's a lot of work, but it's kind of your own fault for letting yourself be bamboozled by those Symantec yobbos.


(In reply to Andrew Swan [:aswan] from comment #4)
> The only real solution here is for extension developers to build in features that make it easy to
> save/export any important data that might be created from within an extension.

That would be lovely, but it's not a solution. Developers will continue to do what they have done, they have no incentive to make it easier for me to drop their their app but keep the data, and some would rather scorch the earth as they go (bug 1213990 comment 7). In the scenario I gave you no solution that requires the user to anticipate data loss isn't a solution because the user doesn't realize that she's about to lose data.

> There are lots of ways to do this and we'll soon be landing browser.storage.sync

How is leaving orphaned data on a server safer than leaving orphaned data on my local drive? (I asked Yahoo; they haven't responded.) Either you're gonna delete the remote data for the same reason, or else it wasn't necessary to delete the data locally. (I am looking forward to storage.sync for other reasons, though.)

Comment 6

[Nancy Grossman]

Oops, I meant "buffaloed"; of course you weren't bamboozled (bug 1213990 comment 15).

Comment 7

[Nancy Grossman]

A UI mock-up of the two approaches: http://imgur.com/a/souPE

The 'keep the data' checkbox alone would suffice. It reminds me that there is a side-effect, and allows me to avoid that side effect. For continuity with existing Firefox behaviour I'd let the user opt-in to deleting storage ('checked' as the default in the mock-up).

Comment 8

[Nancy Grossman]

OK, this is not the same issue so I submitted bug 1314114. Sorry Tom Schuster for smudging your bug report.