Comment 10 for bug 288236

Created an attachment (id=305318)
patch v3: doesn't clear global prefs

(In reply to comment #8)
> I'm a bit concerned that this will be unexpected to some users, who won't
> expect that clearing "Browsing History" will clear site-specific prefs. Are we
> sure that the prefs being cleared are easy to recover? What if an extension
> sets site-specific prefs that the user went through a lot of trouble to set up?

It's a good point. We can't be sure, since extensions could set prefs that are harder to recover than text & page zoom.

> Admittedly that's unlikely to be a common scenario, but maybe we could address
> it by making "site specific prefs" an explicit choice in the dialog, rather
> than piggy-backing on "Browsing History"? Perhaps that would be overkill, as
> beltzner mentions.

It seems like overkill for the prefs we currently store in the content pref service, although it's probably not overkill once we extend this functionality to the full set of site-specific prefs, like cookie, popup, image load, and addon installation exceptions, which currently aren't cleared when users clear private data.

And maybe it doesn't make sense to clear these site-specific prefs unless we clear all of them.

(In reply to comment #9)
> Myk: Is there a convention for "global" values in the content pref service
> (e.g. a NULL group like for "full-zoom")? If so, using:
>
> dbConnection.executeSimpleSQL("DELETE FROM prefs WHERE groupID IS NOT NULL");
>
> might work without deleting such global values.

Yup, the convention is that global values have a NULL groupID, so your suggested query is exactly right.

Here's a version of the patch that doesn't delete global prefs. It includes an additional test for that.

Nevertheless, I do think Gavin's concern is legit, so I'm not quite sure how to proceed.