Closed Bug 469158 Opened 11 years ago Closed 11 years ago

Remove the 'privacy.sanitize.promptOnSanitize' preference

Categories

(Firefox :: Private Browsing, defect)

defect
Not set

Tracking

()

VERIFIED FIXED
Firefox 3.6a1

People

(Reporter: u88484, Assigned: ehsan)

References

(Depends on 1 open bug)

Details

(4 keywords)

Attachments

(1 file)

The ellipsis from "Clear recent history" in about:privatebrowsing need to be removed when 'privacy.sanitize.promptOnSanitize' is true.

I accidentally cleared my recent history because I seen the ellipsis and thought the prompt was going to open asking me what I wanted to clear.  Turns out that if you have "Ask me before clearing my private data" not checked in the options, you won't be asked here even though there are ellipsis indicating a dialog will be opened.  

So bug 463810 comment 0 was somewhat flawed in his statement, "No history is cleared without further input from the user"

Now when I check or uncheck that option in the options menu, the ellipsis are added or removed from the tools menu depending on the how the pref is set but this is not so for about:privatebrowsing.
Flags: wanted-firefox3.1?
Flags: blocking-firefox3.1?
when 'privacy.sanitize.promptOnSanitize' is FALSE
Summary: Remove ellipsis from "Clear recent history" in about:privatebrowsing when 'privacy.sanitize.promptOnSanitize' is true → Remove ellipsis from "Clear recent history" in about:privatebrowsing when 'privacy.sanitize.promptOnSanitize' is false
I agree that this is a very serious issue, but I think the correct fix would be to ignore privacy.sanitize.promptOnSanitize and always show the dialog regardless of its value.

The rationale is that the CRH dialog here is mostly used to clear the browsing history of a particular time span, when users realize that they had visited some sites without entering the private mode.  Therefore, relying on the default values provided in the CRH dialog and respecting privacy.sanitize.promptOnSanitize would mean that they may lose an amount of history which was not really supposed to be wiped out.

There is of course the fact that we're past string freeze.  :-)

Alex, what do you think?
Assignee: nobody → ehsan.akhgari
Status: NEW → ASSIGNED
I never user clear private data and can only think that the options were set the way they were from when I was testing this feature when it landed (yes that long ago).  So when I seen the ellipsis, I assumed I would be prompted as I had forgotten about the clear private data settings and thought clear recent history would prompt me for different options anyways but as we can see that did not happen and now my awesomebar is not so awesome and I have to actually type URLs again :(

I think to always prompt is the way to go because users might not always remember what they have set and it is easier to accidentally click that button then it is to go to Tools menu and select the entry there.
>Alex, what do you think?

How did privacy.sanitize.promptOnSanitize get changed?  Since we are removing the prompt when clearing stuff on close, (or even the option in the UI) should we also remove the pref?  Also, if the hidden pref gets flipped by someone directly altering stuff in about:config, we of course have that initial warning message for a reason.
(In reply to comment #4)
> >Alex, what do you think?
> How did privacy.sanitize.promptOnSanitize get changed?
I manually changed it through the options by unchecking the box "Ask me before clearing my private data".

> Since we are removing the prompt when clearing stuff on close, (or even the 
> option in the UI) should we also remove the pref?
Why would that prompt be removed?  That is just insane to remove a prompt to clear stored data.

> Also, if the hidden pref gets flipped by someone directly altering stuff in  > about:config, we of course have that initial warning message for a reason.
That is in no way a good enough reason to WONTFIX this bug as it seems the way your leaning towards.  

People set things and forget (like myself) then one day needs to use the clear private data feature to clear something specific and they need a prompt that lets them choose what to clear.  Making a user dig into the options everytime they want to clear something but not another is not good.
New options for managing your privacy include:

-Don't remember anything (basically private browsing mode all the time)
-Clear everything on exit (but we aren't going to ask you every time like we used to)
-Using private browsing mode to not store stuff in the first place
-Using the clear recent history dialog to clear a specific time period, or all time

>That is just insane to remove a prompt to
>clear stored data.

The user has very clearly indicated "don't remember anything" (if they literally select the drop down "Firefox should not remember anything")

>That is in no way a good enough reason to WONTFIX this bug as it seems the way
>your leaning towards.  

We should still fix the bug, but my points are:

-we need to ignore the pref if the user is accessing the dialog box from about:private browsing
-I think this about:config pref is now entirely vestigial, so perhaps we should remove it entirely?
-If we don't remove it, the only users effected will be people who manually set it in about:config
(In reply to comment #6)
> We should still fix the bug, but my points are:

Oh ok.  It just seemed like you were leaning WONTFIX

> -we need to ignore the pref if the user is accessing the dialog box from
> about:private browsing

Ignore the pref as in always prompt?

Could you point me to the bug/discussion/mockups with the rework for managing your privacy so I can better understand where it will lead to.  

My main concern is that the button is easy to accidentally click and wipe out data.  I know this doesn't matter to anyone but since I was digging through the about:privatebrowsing source, the oncommand for the button is openSanitizeDialog()" which it doesn't actually open the dialog...not that a command name means much but just wanted to point that out in case it means something else is wrong since the dialog wasn't actually opened and it technically should be but there is a bug within the code that is called.
>Could you point me to the bug/discussion/mockups with the rework for managing
>your privacy so I can better understand where it will lead to.  

Here is the mockup for the privacy changes:
http://people.mozilla.com/~faaborg/files/shiretoko/privacy_i2.png

Some of the stuff in that mockup is either out of date or not implemented yet, but it covers all the stuff we are thinking about.

The change I was referring to is when the user selects "Firefox should clear private data when it closes" in the privacy prefpane, we will no longer prompt the user every time on exit if they want to clear data.  

>My main concern is that the button is easy to accidentally click and wipe out
>data. 

Yep, that is a bug that needs to be fixed.
I think we really should remove this pref, because there really isn't anywhere that it's going to be useful, considering the new privacy enhancements.
Summary: Remove ellipsis from "Clear recent history" in about:privatebrowsing when 'privacy.sanitize.promptOnSanitize' is false → Remove the 'privacy.sanitize.promptOnSanitize' preference
Attached patch Patch (v1)Splinter Review
Remove the privacy.sanitize.promptOnSanitize preference.

I tried not to introduce any new strings so that the impact on string freeze is minimal.  I have deleted three strings, which I think would be easier for localizers to pick up (or even to ignore if they want).

Also, this patch makes sure that on shutdown, if the browser needs to clear recent history, no prompt gets shown.

I don't know if Sanitizer.jsm is supposed to be used inside the code base or by extensions, but I've updated it anyway.
Attachment #352697 - Flags: review?(mconnor)
Blocks: 462041
Blocking. The ellipses should stay, and we should get this done by the end of the year as that's when we're freezing strings for Beta 3.
Flags: blocking-firefox3.1? → blocking-firefox3.1+
Keywords: late-l10n
Mass moving of all Firefox::General private browsing bugs to Firefox::Private Browsing.
Component: General → Private Browsing
QA Contact: general → private.browsing
Attachment #352697 - Flags: ui-review?(beltzner)
Whiteboard: [needs review mconnor][needs ui-review beltzner]
Flags: wanted-firefox3.1?
Attachment #352697 - Flags: ui-review?(beltzner) → ui-review+
Whiteboard: [needs review mconnor][needs ui-review beltzner] → [needs review mconnor]
Attachment #352697 - Flags: review?(mconnor) → review?(gavin.sharp)
Comment on attachment 352697 [details] [diff] [review]
Patch (v1)

>diff --git a/browser/base/content/sanitize.js b/browser/base/content/sanitize.js

> Sanitizer.sanitize = function(aParentWindow) 

>+  Sanitizer.showUI(aParentWindow);
>+  return null;

In the interest of minimizing last minute changes, this is OK as is, but we should probably get a bug on file on cleaning this code up - the "returns null" behavior is unneeded now and callers shouldn't rely on it.

>   if (prefs.getBoolPref(Sanitizer.prefShutdown) && 
>       !prefs.prefHasUserValue(Sanitizer.prefDidShutdown)) {
>     // this is a shutdown or a startup after an unclean exit
>-    Sanitizer.sanitize(null) || // sanitize() returns null on full success
>+    new Sanitizer().sanitize() || // sanitize() returns null on full success

Why this change?

Same comments apply to the jsm (arg, bug 397719 needs to land!)

>diff --git a/browser/components/preferences/privacy.js b/browser/components/preferences/privacy.js

The comment at the end of this file before clearPrivateDataNow needs to be updated too.
Attachment #352697 - Flags: review?(gavin.sharp) → review+
Blocks: 471812
(In reply to comment #13)
> In the interest of minimizing last minute changes, this is OK as is, but we
> should probably get a bug on file on cleaning this code up - the "returns null"
> behavior is unneeded now and callers shouldn't rely on it.

Filed bug 471812.

> >   if (prefs.getBoolPref(Sanitizer.prefShutdown) && 
> >       !prefs.prefHasUserValue(Sanitizer.prefDidShutdown)) {
> >     // this is a shutdown or a startup after an unclean exit
> >-    Sanitizer.sanitize(null) || // sanitize() returns null on full success
> >+    new Sanitizer().sanitize() || // sanitize() returns null on full success
> 
> Why this change?

To always show the UI.  Otherwise, the latest selection in the UI may be used,
which is probably not what the user wants (note that the new CRH dialog has a
time range).
Landed on mozilla-central <http://hg.mozilla.org/mozilla-central/rev/45f0ebf6eecc>
Status: ASSIGNED → RESOLVED
Closed: 11 years ago
Resolution: --- → FIXED
Whiteboard: [needs review mconnor]
Target Milestone: --- → Firefox 3.2a1
Keywords: user-doc-needed
https://hg.mozilla.org/releases/mozilla-1.9.1/rev/56686b0bed37
Severity: critical → normal
Keywords: fixed1.9.1
Target Milestone: Firefox 3.2a1 → Firefox 3.1b3
Target Milestone: Firefox 3.1b3 → Firefox 3.2a1
Flags: in-litmus?
No longer blocks: 471812
Depends on: 471812
No longer depends on: 463810
(In reply to comment #14)
> (In reply to comment #13)
> > In the interest of minimizing last minute changes, this is OK as is, but we
> > should probably get a bug on file on cleaning this code up - the "returns null"
> > behavior is unneeded now and callers shouldn't rely on it.
> 
> Filed bug 471812.
> 
> > >   if (prefs.getBoolPref(Sanitizer.prefShutdown) && 
> > >       !prefs.prefHasUserValue(Sanitizer.prefDidShutdown)) {
> > >     // this is a shutdown or a startup after an unclean exit
> > >-    Sanitizer.sanitize(null) || // sanitize() returns null on full success
> > >+    new Sanitizer().sanitize() || // sanitize() returns null on full success
> > 
> > Why this change?
> 
> To always show the UI.  Otherwise, the latest selection in the UI may be used,
> which is probably not what the user wants (note that the new CRH dialog has a
> time range).

but if you use new Sanitizer().sanitize() you NEVER call Sanitizer.sanitize that call Sanitizer.showUI you always call Sanitizer.prototype.sanitize !!!
with this bug we never see the UI on exit
(In reply to comment #17)
> but if you use new Sanitizer().sanitize() you NEVER call Sanitizer.sanitize
> that call Sanitizer.showUI you always call Sanitizer.prototype.sanitize !!!
> with this bug we never see the UI on exit

Actually, I had my mind twisted last night, since that is what I did on purpose! (see comment 10).  The rationale is that the privacy prefpage checkbox says "Always clear my private data when I close Firefox", and there is a "Settings" button next to it which is used to determine what kind of private data gets deleted.  Nothing time-related is mentioned there, so it doesn't make sense to prompt the user on shutdown (because it would look more like a prompt to ask what to delete, rather than what timespan to delete), and the fact that from the strings we show in the UI the user can infer that this setting clear all of the data...
so if i understand you the new behavior is:

- Tools > Clear Recent History... - Always show the UI
- about:privatebrowsing clearing your recent history  - Always show the UI
- clear private data on exit - NEVER show the UI

is that true ?
(In reply to comment #19)
> so if i understand you the new behavior is:
> 
> - Tools > Clear Recent History... - Always show the UI
> - about:privatebrowsing clearing your recent history  - Always show the UI
> - clear private data on exit - NEVER show the UI
> 
> is that true ?

Yes.
in Tools > Options > privacy:
if "Always clear my private data when i close Minefield" is not checked then settings... button should be disabled
(In reply to comment #21)
> in Tools > Options > privacy:
> if "Always clear my private data when i close Minefield" is not checked then
> settings... button should be disabled

Sounds logical.  Can you file a bug on that, please?
(In reply to comment #22)
> (In reply to comment #21)
> > in Tools > Options > privacy:
> > if "Always clear my private data when i close Minefield" is not checked then
> > settings... button should be disabled
> 
> Sounds logical.  Can you file a bug on that, please?

 Bug 471898 -  In Tools > Options > Privacy: if sanitize on shutdown is off settings... button should be disabled
In Comment 11 mentions the ellipsis should stay, but now that the button is gone and there is a only a link, I just see a period at the end of the line.
Target Milestone: Firefox 3.2a1 → Firefox 3.1b3
(In reply to comment #24)
> In Comment 11 mentions the ellipsis should stay, but now that the button is
> gone and there is a only a link, I just see a period at the end of the line.

This text was updated in bug 471627, and Alex didn't include an ellipsis there.  I don't think an ellipsis is needed where the UI is a link, but Alex can you please confirm that this is the desired behavior?
will these changes impact on 
https://bugzilla.mozilla.org/show_bug.cgi?id=470348
"Clear private data on shutdown does not delete history if "ask me before..." is enabled"
Why can I no longer prevent Minefield from prompting me every time I want to "Clear Recent History"?!?  This is a step back!

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2a1pre) Gecko/20090104 Minefield/3.2a1pre ID:20090104073927

~B
Because with the new dialog, you have an option to choose a desired time range for clearing the private data, and we can't automatically guess what time range you're going to pick.
IMHO that should be an option within the settings for Clear Private Data.  Why allow me to set what I want to be cleared upon closing of FF and not let that apply to recent history via a check box?  Seems like we're forcing more manual steps on users.

~B
I don't personally agree, but it'd be best if you would file a bug on that.
Duplicate of this bug: 463186
Blocks: 464208
>Alex didn't include an ellipsis there.
> I don't think an ellipsis is needed where the UI is a link, but Alex can you
>please confirm that this is the desired behavior?

No need for an ellipsis.  The purpose of an ellipsis is to indicate that a navigation is going to occur (like going to a window), as opposed to an immediate action taking place.  So "Print..." means that you are going to see more options, while "Print" means that clicking will cause something to come out of your printer.  In the case of hyperlinks, they are all navigation-based, so the ellipsis-ness is implied by the underline.  This however is the first instance of a URL pointing to chrome, and if when we create hyperlinks in the future we need to be very careful that they do not carry out an action.
>Why can I no longer prevent Minefield from prompting me every time I want to
>"Clear Recent History"?!?  This is a step back!

You have three options:

1) Manually clear recent history whenever you want
2) Automatically have Firefox clear your recent history on close (without bothering you)
3) Automatically have Firefox never store anything to begin with (without bothering you)

The additional choice of automatically presenting manual controls by means of a forced dialog on close was removed because it doesn't really match any common use case that isn't covered by the above three options, and was mostly designed based around the underlying implementation.
(In reply to comment #33)
> You have three options:
> 
> 1) Manually clear recent history whenever you want
> 2) Automatically have Firefox clear your recent history on close (without
> bothering you)
> 3) Automatically have Firefox never store anything to begin with (without
> bothering you)

we don't have UI for #3
maybe we need to add browser.privatebrowsing.autostart to Tools > Options > Privacy ?
verified fixed on the 1.9.1 branch using  Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1b3pre) Gecko/20090115 Shiretoko/3.1b3pre and following the steps in Comment 19.
(In reply to comment #33)

> The additional choice of automatically presenting manual controls by means of a
> forced dialog on close was removed because it doesn't really match any common
> use case that isn't covered by the above three options, and was mostly designed
> based around the underlying implementation.

Of course there is a usecase. Take this: On a whim, I'll buy some opera tickets for my partner. I'll forget to use private browsing. I complete then carry on browsing. She comes into the room and ask to use my computer for a second. In the past I've been able to stealthily remove all potentially incriminating sites by hitting ctrl-shift-del without any dialog popping open. Now one is forced on me, prompting questions about why I want to clear my history. Do you want a bug opening for this?
(In reply to comment #36)
> (In reply to comment #33)
> 
> > The additional choice of automatically presenting manual controls by means of a
> > forced dialog on close was removed because it doesn't really match any common
> > use case that isn't covered by the above three options, and was mostly designed
> > based around the underlying implementation.
> 
> Of course there is a usecase. Take this: On a whim, I'll buy some opera tickets
> for my partner. I'll forget to use private browsing. I complete then carry on
> browsing. She comes into the room and ask to use my computer for a second. In
> the past I've been able to stealthily remove all potentially incriminating
> sites by hitting ctrl-shift-del without any dialog popping open. Now one is
> forced on me, prompting questions about why I want to clear my history. Do you
> want a bug opening for this?

This is the "boss key" use case, mentioned in bug 463186 comment 0.  Alex didn't say there wasn't a use case, he said that it wasn't one of the common use cases for this feature.  If you want to re-open the question of whether it should be included in Firefox, then yes, filing a bug is appropriate.  I want to caution you that it's plausible that bug will be marked WONTFIX, and that it is a feature better served by an add-on. If one doesn't already exist for this functionality, it should be pretty straightforward to create one. I'm not prejudging the question though, if you want to file that bug to have that discussion, you should.
https://litmus.mozilla.org/show_test.cgi?id=7476 added to Litmus.
Flags: in-litmus? → in-litmus+
Verified with Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2a1pre) Gecko/20090203 Minefield/3.2a1pre ID:20090203020449 and the steps in comment 19.
Status: RESOLVED → VERIFIED
Target Milestone: Firefox 3.1b3 → Firefox 3.2a1
This bug only removed code, so there's nothing to automatically test here.
Flags: in-testsuite-
This is marked fixed, but in 3.6.4 on linux I am still being prompted by a pop-up each and every time I clear my browsing data.  Maybe it is actually fixed and the pop-up I am seeing is unexpected behavior?

I very frequently clear my browsing history, cookies, etc..  With this change, I must jump through the hoop of responding to a very annoying popup each time I do.  How is it my browser is now forcing pop-ups down my throat? This is progress?  And adblock won't block this firefox pop-up, but if I install yet another extension, maybe it will?  Is that intended as a joke?

After a recent firefox upgrade, I was forced to install Yet Another Extension to get the Clear Recent History back in the right spot on the menu and avoid the pop-up.  Now that I have again upgraded (only for security reasons, to 3.6.4), that extenion no longer works.  The author has not updated it, so now I jump through more hoops.  My previous about:config settings that allowed me to override version checking no longer work.

So, here I am again, dealing with UI change issues that are fairly tedious.  I've read this entire thread and saw no reasonable justification for changing the previous behavior.  It's nice that someone added a time-bounding feature, but forcing All of us to endure that feature just to 'expose it to the world!' seems punitive.

For those of us who upgade for security fixes (maybe 3.6.4 will leak a little less memory?), having UI changes forced upon us is a drag.  Constant prompting is progress?  The mind boggles.

Thanks!
You have three options:

1) Manually clear recent history whenever you want
2) Automatically have Firefox clear your recent history on close (without
bothering you)
3) Automatically have Firefox never store anything to begin with (without
bothering you)
Yes, but how can I avoid the pop-up each time I clear history?

The about:config option to not be asked is no longer working.  That seemed like a fine solution.  The pulldown menu needs no confirmation - the actions it takes are already specified in my Preferences.

#2, I already do.  But that does not solve my desire for privacy when moving from site to site
#3 Is not a solution because (unfortunately) I need temporary cookies to interact with many sites

Also, I just found a configuration data loss risk with the new pop-up.  On my screen the "Site Preferences" field is about 3mm from the "Clear Now" button.  I missed Clear Now, and inadvertantly selected "Site Preferences"..  Woosh, my 1500 site preferences were lost.  So much for user confirmation.  Fortunately, I was able to restore the preferences.sqlite file from a backup.  For a lot of folks, that would not be quite so easy.
REPEAT:

Yes, but how can I avoid the pop-up each time I clear history?

The about:config option to not be asked is no longer working.  That seemed like
a fine solution.  The pulldown menu needs no confirmation - the actions it
takes are already specified in my Preferences.

#2, I already do.  But that does not solve my desire for privacy when moving
from site to site
#3 Is not a solution because (unfortunately) I need temporary cookies to
interact with many sites

Also, I just found a configuration data loss risk with the new pop-up.  On my
screen the "Site Preferences" field is about 3mm from the "Clear Now" button. 
I missed Clear Now, and inadvertantly selected "Site Preferences"..  Woosh, my
1500 site preferences were lost.  So much for user confirmation.  Fortunately,
I was able to restore the preferences.sqlite file from a backup.  For a lot of
folks, that would not be quite so easy.
I don't really understand what you're proposing here.  Are you suggesting that we shouldn't show the Clear Recent History menu item when you select Tools > Clear Recent History...?
> I don't really understand what you're proposing here.  Are you suggesting that
> we shouldn't show the Clear Recent History menu item when you select Tools >
> Clear Recent History...?

In the past, we could set 'privacy.sanitize.promptOnSanitize' to false, and not be bothered by further prompts.  3.5.1 eliminated that choice, and ignores that user preference.  

I have yet to see a cognizant explanation on how that benefits user privacy, or users. It is an additional hoop we must jump through to protect our privacy.

We should have the option to purge personal state information from the browser with one click, max.   And we had that, but it was eliminated.

Does anyone actually think users need to be protected from setting 'privacy.sanitize.promptOnSanitize' to false by accident?
(In reply to comment #47)
> Does anyone actually think users need to be protected from setting
> 'privacy.sanitize.promptOnSanitize' to false by accident?

Yes.  What happens, for example, when you open the Tools menu, highlight Start Private Browsing, and hit Clear Recent History by mistake when you meant to hit Start Private Browsing?  You'll end up with parts of the history deleted, which is not what you wanted, and that deletion is not recoverable, so you'll end up losing some data.
> What happens, for example, when you open the Tools menu, highlight Start
> Private Browsing, and hit Clear Recent History by mistake when you meant to hit
> Start Private Browsing?  You'll end up with parts of the history deleted, which
> is not what you wanted, and that deletion is not recoverable, so you'll end up
> losing some data.

But isn't it true that the user would only lose "some data" if they had *actively enabled* 'privacy.sanitize.promptOnSanitize' to false?

So given that this requires a manual config action by the user, I don't see where that is a problem.  Also, wouldn't the specific "some data" in question already have been selected by the user as state they do not typically wish to retain?

Do you see how this penalizes experienced users who want a more efficient and streamlined user interface?   I myself don't care if I have to toggle the behavior via about:config.  Is dumbing down about:config options really the future direction and intent?

What do you think about the risk to "site preferences" data by the new pop-up?
The new pop-up makes it very easy to accidently toggle deletion of "site preferences" when responding to the clear recent history pop-up.  On my browser under Linux, the entire row for "site preferences" is active (beyond the button, beyond the text, spanning the entire width of the region), and it is only 3mm from the "Clear now". So in the interest of extra user data "safety", I would argue that the current behavior actually increases the data loss risk to the user.  I have already lost my site preferences a couple of times, but I have a backup.


I appreciate your concerns about users losing state and configuration data. However, compromising browser interface functionality and efficiency seems like an indirect approach with significant side-effects.  Wouldn't it be more appropriate to give the user a way to backup/version configuration and state data? I imagine there are already plugins available that do that.

Thank you for your reply! :)
One other thing to note here is that the Clear Recent History option is different to the old Clear Private Data option in that it takes a time range parameter, and there is no way to read the users' minds to figure out which time range they want to clear if we maintained the privacy.sanitize.promptOnSanitize pref.
How many users actually want to fiddle with a time range when clearing their selected private data?   I question whether there really is enough use of the time feature to justify removing the old behavior.  The addition of that new functionality should not have broken the old feature/behavior.

Also, the minimum time range is one hour.  That isn't very flexible.  Maybe it would be more compelling if there was a time-ordered display of state data that would show the range that will be cleared, with a slider to select the specific time range.. But that is very much drifting into functionality that probably should be an extension.

So you say there is no way to read the users' mind... I respond that the majority of users don't care about the time range.  And if they modify privacy.sanitize.promptOnSanitize, then they just want to wipe the data with no regard to a time range.  It would not be unreasonable to save a user specified default time range, but I don't think that is essential.

Did you look at the "site preferences" data risk issue?
(In reply to comment #51)
> How many users actually want to fiddle with a time range when clearing their
> selected private data?   I question whether there really is enough use of the
> time feature to justify removing the old behavior.  The addition of that new
> functionality should not have broken the old feature/behavior.

I don't have data on that.  I just know that I've used all of the options in that drop down at some point, depending on the reason that I was clearing the data.

> Also, the minimum time range is one hour.  That isn't very flexible.  Maybe it
> would be more compelling if there was a time-ordered display of state data that
> would show the range that will be cleared, with a slider to select the specific
> time range.. But that is very much drifting into functionality that probably
> should be an extension.

There were plans to do something like that, but they didn't get finished in time for Firefox 3.5 and after that nobody has worked actively on them.

> So you say there is no way to read the users' mind... I respond that the
> majority of users don't care about the time range.  And if they modify
> privacy.sanitize.promptOnSanitize, then they just want to wipe the data with no
> regard to a time range.  It would not be unreasonable to save a user specified
> default time range, but I don't think that is essential.

Do you have data to back up your claim?

> Did you look at the "site preferences" data risk issue?

That's a separate issue which is not immediately relevant to the current discussion.  If you think that's something worth looking into, you should file a new bug.
You need to log in before you can comment on or make changes to this bug.