513421 - Never remember history option should notify the user that previous history won't be removed

Status: NEW

(Toolkit :: Data Sanitization, enhancement, P3)

Description

[Gavin Stokes]

User-Agent:       Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.1.2) Gecko/20090729 Firefox/3.5.2
Build Identifier: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.1.2) Gecko/20090729 Firefox/3.5.2

I have "never remember history" selected under Privacy, but the auto-completion will still pull entries from history as I type in the address bar.  I verified that these entries are not bookmarks, by switching the location-bar suggestion option to "bookmarks"; this stops the history entries from showing up.  If I switch back to "History and Bookmarks", the behavior resumes.

I see a few potentially related bugs about the address-bar history not being cleared or honoring specific deletions, but none that mentions this global setting.

Reproducible: Always

Steps to Reproduce:
1. Have Firefox set to never remember history.
2. Visit some sites for which you don't have bookmarks.  Note a few of the characters at the beginning of the URL.
3. Shut down and restart Firefox.
4. Type the first few characters of one of the URLs you noted.
Actual Results:  
Firefox suggested URLs from history, which it was supposed to have forgotten.

Expected Results:  
Nothing is suggested.

Comment 1

[Mardeg]

How does that global setting affect these about:config prefs?
browser.history_expire_days
browser.history_expire_sites
I would have thought it'd set both those to 0. If it doesn't the question I think this bug is asking is why not?

Comment 2

[Gavin Stokes]

Well, the real question is how can the address bar pull entries from history, when that history is not supposed to exist at all?

Not that it should matter, but the history it's pulling is pretty old, more than a day.

Comment 3

[Drew Willcoxon :adw]

Did you select Never remember history the moment you started using Firefox?  Never remember history prevents Firefox from recording history -- it doesn't go back and delete history you already have.  To do that, select Tools > Clear Recent History, select Everything from the dropdown, make sure Browsing & Download History is checked, and click Clear Now.  Does that fix your problem?

Comment 4

[Gavin Stokes]

I'm not sure when I activated "never remember history".  "Clear recent history" is greyed out.

Comment 5

[Drew Willcoxon :adw]

Oh right, it's greyed out because you chose Never remember history (bug 463607).  Go back to the privacy options and select Remember history.  Then Clear Recent History as I described.  You can switch back to Never remember after that.  Does that work?

Comment 6

[Marco Bonardo [:mak] (Away 10-21 August)]

adding dependancy on bug 463607 and confirming, actually could just be duped, but i want to be sure that fix will allow users to clear history while in PB mode (so that it will cover this case), and could even be worth writing a test for that.

btw, if ehsan is going to fix that with a test in the above bug, feel free to just dupe.

Ideally could even be smart to ask the user if he wants to clear all previous history when he toggles "Never rememeber history" (i'd expect that to be automatic, but dataloss is at a step). Adding uiwanted for this.

Comment 7

[Gavin Stokes]

"Go back to the privacy options and select Remember history.  Then
Clear Recent History as I described.  You can switch back to Never remember
after that.  Does that work?"

Yep.

Comment 8

[Drew Willcoxon :adw]

(In reply to comment #6)
> adding dependancy on bug 463607 and confirming, actually could just be duped

That's not what this bug is about.  Gavin expected the Never remember history option to retroactively delete history.  Since that's not how that option is designed to work, this could be INVALID, but since I don't think it's a strange assumption to make, I'll let Ehsan or UX make that call.

Comment 9

[Marco Bonardo [:mak] (Away 10-21 August)]

we should rephrase the pref, and/or add an option "also clear existing history"... At least if we are going to remove old history we should ask to the user to avoid dataloss, but we don't want to nag him.

Comment 10

[(no longer active)]

(In reply to comment #8)
> That's not what this bug is about.  Gavin expected the Never remember history
> option to retroactively delete history.  Since that's not how that option is
> designed to work, this could be INVALID, but since I don't think it's a strange
> assumption to make, I'll let Ehsan or UX make that call.

I don't think "Never remember history" means "Go back and clear the history that is already there as well", so I'd vote for WONTFIX here.  But I'll let Alex weigh in as well.

Until we definitely believe that this is a valid enhancement request, I'm setting this back to the Unconfirmed status.

Comment 11

[Gavin Stokes]

I think Marco's suggestion (adding an option to clear history when activating "never remember") is ideal, and doesn't hamper anyone.

Comment 12

[Alex Faaborg [:faaborg] (Firefox UX)]

The interface in the privacy prefpane currently reads "you may want to _clear your recent history_, or _remove individual cookies_"  while it is kind of uncommon for users to read messages (not saying that to be derogatory, it is simply true), I feel like we've established a pretty good path to the Clear Recent History window by linking to it.

We could consider a custom message like:

Firefox has currently recorded 57 days of history would you like to _clear everything_?

and then only display that message if there actually is history stored.

Comment 13

[Marco Bonardo [:mak] (Away 10-21 August)]

would that be an additional message to the above one with a link pointing to CRH dialog with Everything option selected?
PS: we don't have a method to tell how many days of history are present, but adding it would not be hard.

Comment 14

[Marco Bonardo [:mak] (Away 10-21 August)]

I'm confirming as enhancement, to investigate ways to better notify the user about what is about to happen. Comment 12 is a first possible implementation.

Comment 15

[Alex Faaborg [:faaborg] (Firefox UX)]

It would replace the text on the never remember history state ("you may want to clear all current history")  So either the message about how much history exists would be displayed, or nothing would be displayed (just the first part about it being the same as private browsing).

Comment 16

[Gavin Stokes]

I still vote for Marco's suggestion, with "also clear existing history" to default to TRUE.

I would, in fact, expect "never remember history" to clear all history.  The statement is pretty straightforward:  You're saying never remember history, regardless of when that history was acquired.  If the address bar is popping past URLs up, it's "remembering history" after I clearly told it not to.

If I saw something last year and then yesterday you hypnotized me and said "Never remember that", you wouldn't hear me bringing it up tomorrow (assuming a successful hypnosis).

Comment 17

[Alex Faaborg [:faaborg] (Firefox UX)]

I agree that nearly all of the time users who want to turn history off also want to clear all existing history, but due to the dataloss implications we really need to make the action of deleting everything a bit more explicit than just selecting an item in a drop down.

We could go as far as to add an information or (error?) icon to the message in the privacy prefpane to draw more attention to it.

Comment 19

[Tom Lowenthal]

Another alternative would be to clear existing history only after the browser gets closed after "never remember..." is selected. I have no problem with the prompted delete either.

Once a user has picked "never remember..." none of the other options are visible, including the option to clear history when Firefox closes. This creates a confusing experience for a user who is in the above position of having disabled history, but who still sees a history items in the new tab pane or awesome bar autocomplete.

Comment 21

[(no longer active)]

(In reply to comment #19)
> Another alternative would be to clear existing history only after the browser
> gets closed after "never remember..." is selected. I have no problem with the
> prompted delete either.

We used to have that option and we had to remove it because:

1. Clearing the history at shutdown could be arbitrarily expensive and can make the shutdown process very slow.
2. Your history will be leaked if you crash or shutdown ungracefully some other way, so we need to check for that case at startup as well, which makes the startup process slower too.

Comment 22

[Tom Lowenthal]

(In reply to Ehsan Akhgari [:ehsan] from comment #21)
> We used to have that option and we had to remove it because:

We currently have this feature. If a user picks "use custom settings...", there's the option to clear private data when Firefox closes, but this option is hidden if a user picks "never remember...". Given the apparent user expectation that "never remember..." means that there's no history (even of prior events), clearing on shutdown seems to fill this need, while avoiding the risk of accidentally picking that option and nuking one's history.

Comment 23

[(no longer active)]

(In reply to comment #22)
> (In reply to Ehsan Akhgari [:ehsan] from comment #21)
> > We used to have that option and we had to remove it because:
> 
> We currently have this feature. If a user picks "use custom settings...",
> there's the option to clear private data when Firefox closes,

Ah right, sorry.  There was discussion about removing this feature a while back and I was in support of that proposal, and I thought that somebody was working on that patch, but apparently I was wrong.  There's just no way to implement this feature efficiently.

> but this option
> is hidden if a user picks "never remember...". Given the apparent user
> expectation that "never remember..." means that there's no history (even of
> prior events), clearing on shutdown seems to fill this need, while avoiding the
> risk of accidentally picking that option and nuking one's history.

I don't think that addresses the concerns in comment 10 and comment 17 at all.  I have yet to see an argument which convinces me that we want to delete the user's history without them explicitly asking for it.  The dataloss implication outweighs the expectation that we're suspecting some users might have.

Comment 24

[Gavin Stokes]

Then don't delete it.  Simply NEVER REMEMBER IT, which is what the UI promises.  I pointed out in comment 16 why one would expect "never remember" to stop historical data from showing up in the UI.  I said never remember it.  That means don't remember it in suggestions, don't remember it in history lists, or anywhere else.  The user has made a very clear choice here, so why are we second-guessing it?

Also, Marco already suggested a perfectly clear and convenient solution that addresses everyone's concerns: "...ask the user if he wants to clear all previous history when he toggles 'Never rememeber history.'"

Put a checkbox saying "Clear all existing history" next to the button, default it to Yes, and be done with it.  Is there some reason that this solution isn't workable?

Comment 25

[(no longer active)]

(In reply to comment #24)
> Then don't delete it.  Simply NEVER REMEMBER IT, which is what the UI promises.

That is what the current code does!

Comment 26

[Gavin Stokes]

When "remember history" is OFF, Firefox still remembers it in the address bar.  That's what this report is about.

Also, what is wrong with Marco's suggestion?  Why continually dodge this question?  It's a perfectly good solution.  Why not implement it?  It addresses everyone's concerns.

Why not implement Marco's suggestion?

Do I need to ask again?

Comment 27

[(no longer active)]

(In reply to comment #26)
> When "remember history" is OFF, Firefox still remembers it in the address bar. 
> That's what this report is about.

No, it's not!

> Also, what is wrong with Marco's suggestion?  Why continually dodge this
> question?  It's a perfectly good solution.  Why not implement it?  It addresses
> everyone's concerns.
> 
> Why not implement Marco's suggestion?

I have nothing against that.  :-)

Comment 28

[Nick Levinson]

I told FF to Never Remember History and FF agreed, so there's no ambivalence from me about old vs. new history. I don't want the history. Period. And FF promised it would forget. So it's supposed to, or the command should be renamed, or an explicit option to preserve the old should be provided. If the option is not exercised, then deletion should be immediate, total, and irrecoverable.

If forgetting is potentially too slow, a solution is to put everything that would be in that history into a folder as the item is created. For example, when a URL is visited, the URL would be written only into that directory (and only momentarily read from there to anywhere else it's wanted). Then, when all is done, deleting requires only deleting or emptying the folder (and, if the operating system allows a choice, not trashing but irrevocably deleting). Then it won't be necessary to rewrite files. Deleting is probably faster than rewriting files.

I tested deletion speed by copying a folder within my hard drive; it contained 648 items totalling 52.2 MB, which would be equivalent to more cookies than almost any individual user has at one time (an organizational server may have more, but those servers are likely faster than my laptop). Unrecoverable deletion took about one second. When I made about nine of those folders with the same contents, unrecoverable deletion took about one second per folder. Trashing two such folders was almost instantaneous; emptying the trash to unrecoverability took about two seconds. On a server, high-volume trash emptying can be automatically done at intervals, such as with a cron job. This kind of time frame is not too long during a restart or shutdown. For the unusual case where it is too slow, an option can offer deletion only on request, in a manner to support cron or some such.

Comment 29

[Nick Levinson]

Re comment 28 (mine): See also bug 1201354.

Comment 30

[BugBot [:suhaib / :marco]]

The bug assignee didn't login in Bugzilla in the last 7 months.
:jaws, could you have a look please?
For more information, please visit auto_nag documentation.

Comment 32

[Harshit Sohaney [:hsohaney]]

Wanted to give my 2 cents on this!
We should add an option in the alert that appears when restarting Nightly, asking users: "Also clear all existing data and restart." Including this in the alert reduces the number of steps users need to remember when selecting "Never remember history."

Do we have any telemetry on how many users enable this option? Also, what might be preventing them from switching to Always Private Browsing or Clear on Shutdown instead?

Comment 33

[Gavin Stokes]

It is 12 years later, and still no one has answered why you don't just implement Marco's suggestion, made 15 years ago:

we should rephrase the pref, and/or add an option "also clear existing history"... At least if we are going to remove old history we should ask to the user to avoid dataloss, but we don't want to nag him.

Comment 34

[Harshit Sohaney [:hsohaney]]

We intend on changing the wording in the preferences to say something along the lines of

Nightly must restart to enable "Never remember history". Existing history data is unaffected by this setting

Comment 35

[Gavin Stokes]

Thanks. That's better than nothing, but the name of the command is still wrong. Firefox will still remember the history accrued up to that point, making the text factually incorrect. The actual behavior is "don't add any more history," which no one would guess and, I submit, almost nobody would intend.

Comment 36

[krish.patel]

Hi, could I take on this bug?

Comment 37

[Manuel Bucher [:manuel] {{ FYI: OOO Jul 30 - Aug 16 }}]

Hi, please do :)

Comment 38

[krish.patel]

Attachment: Bug 513421 - Tell users that existing history is kept when turning on permanent private browsing. r?manuel

Comment 39

[Harshit Sohaney [:hsohaney]]

Hey Meridel, wanted to get UX input on this bug. Our initial thoughts were to just update the string to let the user know that their previous history is not being cleared.
Let me know if you need any more context on this!

Comment 40

[Meridel [:meridel]]

Hi Harshit! Can you help bring me up to speed on the context? Namely, can you describe why we want to make the modification and a screenshot of the current message + where/when it appears? Since this is old bug with many years of history, getting a quick summary will save us time. Thanks.

Comment 41

[Harshit Sohaney [:hsohaney]]

Attachment: never_remember_history_ss.png

The problem arises in about:preferences > Privacy & Security > History. Users have the option to select "Never remember history" from the dropdown. Based on this bug, there can be some confusion once a user switches to this setting, as it implies that Firefox will never remember history, but it doesn't necessarily forget the history saved so far. This can be misleading, as users might expect that their previous history data will be removed upon selecting this option.

Based on Comment 9, a possible solution is to simply inform the user that selecting this option will not remove existing history. Comment 12 suggests an alternative: offering the user a dialog that allows them to clear previous history when choosing this setting from the dropdown. These are possible options, but it would be great to get some UX input on this.

Hope this clears it up!

Comment 42

[BugBot [:suhaib / :marco]]

This good-first-bug hasn't had any activity for 2 months, it is automatically unassigned.
For more information, please visit BugBot documentation.

Comment 43

[Michael Chen]

Hello! I would like to try my hand at this problem, but it seems we still don't have a clear path forwards. Here are the two options I see:

• ... inform the user that selecting this option will not remove existing history.

• [offer] the user a dialog that allows them to clear previous history when choosing this setting from the dropdown.

So does anyone have a consensus on which option to choose?

Comment 44

[Manuel Bucher [:manuel] {{ FYI: OOO Jul 30 - Aug 16 }}]

No consensus to move forward.

This bug already has an attached patch, which in my opinion would be good-to-take. However, it is blocked on UX team review, who weren't able to review it. There is also a chance, that the current patch submitter would update the patch if UX recommends something different, even after the long wait on ux review.

Setting assignee to current patch submitter again.

Comment 45

[BugBot [:suhaib / :marco]]

This good-first-bug hasn't had any activity for 2 months, it is automatically unassigned.
For more information, please visit BugBot documentation.

Comment 46

[Pranjali Srivastava]

Can I work on this? If it's available I would like to take this up.

Comment 47

[Manuel Bucher [:manuel] {{ FYI: OOO Jul 30 - Aug 16 }}]

Same problem as above (comment 44). The patch is not the problem. The content-design/UX-design input is missing here. I'll take a look at bringing this up with UX folks again. I'll remove the good-first-bug until this is resolved.

Comment 48

[Pranjali Srivastava]

Ok, I am sending a patch for this

Comment 49

[Manuel Bucher [:manuel] {{ FYI: OOO Jul 30 - Aug 16 }}]

Sorry if it wasn't clear: No please don't submit a patch. We already have a patch that is working.

Comment 50

[Pranjali Srivastava]

Ok. Apologies for misunderstanding

Comment 51

[Manuel Bucher [:manuel] {{ FYI: OOO Jul 30 - Aug 16 }}]

I've got input from UX now. We can proceed with changing to the following strings:

HL (Headline): Restart [Firefox] now?
Body: Firefox must restart to enable this feature. Your existing browsing history won’t be deleted.
CTA 1 (Button 1): Cancel
CTA 2 (Button 2): Restart now

https://mozilla-hub.atlassian.net/browse/UXREQ-370?focusedCommentId=1370013

@krish: Would you like to pick this up again and update your patch?

Sorry for this to have been taking so long.

Comment 52

[BugBot [:suhaib / :marco]]

Clear a needinfo that is pending on an inactive user.

Inactive users most likely will not respond; if the missing information is essential and cannot be collected another way, the bug maybe should be closed as INCOMPLETE.

For more information, please visit BugBot documentation.

Comment 53

[Dan Mehic]

I've picked this up and implemented the strings UX signed off on in comment 51. Since the bug had been sitting since April and the existing patch was written against a tree layout that no longer exists, I commandeered D238541 rather than opening a new revision, so flod's and hsohaney's earlier review context stays attached. The original work is credited in the commit message — thanks krish.patel.

What the patch does

Three new Fluent messages, used only when permanent private browsing is being turned on:

UX spec (comment 51)	New message ID
HL: Restart [Firefox] now?	restart-private-browsing-title
Body: … Your existing browsing history won’t be deleted.	restart-private-browsing-message
CTA 2: Restart now	restart-private-browsing-ok

CTA 1 needed no work — the existing cancel-no-restart-button already reads exactly Cancel.

confirmRestartPrompt in preferences.js grows an optional trailing options object for per-caller string overrides; anything left unset falls back to the generic IDs. That keeps the change additive, so the other caller (firefoxLabs.mjs) is untouched and no existing string ID changes — which also means there's nothing for a Fluent migration to carry over. Both UI entry points route through onChangePrivateBrowsingAutoStart in privacy.mjs, so the dropdown option and the "Always use private browsing mode" checkbox both get the new wording from one call site.

I confirmed the headline actually renders: CommonDialog hides the title unless the prompt is embedded or on macOS, and this one uses MODAL_TYPE_CONTENT, so it shows on all platforms.

Both browser_warning_permanent_private_browsing.js and ..._srd.js now assert which string set the prompt was invoked with. Green locally (22 passed, 0 failed), and I verified the new assertion genuinely fires by mutating the expected ID and watching it fail.

Three things I'd like your call on

1. The disable direction. Comment 51 only specifies copy for enabling. Turning permanent private browsing back off still uses the generic feature-disable-requires-restart plus the old title and button, so the same checkbox produces differently-styled dialogs in each direction. I left it alone rather than invent unreviewed copy. Is the asymmetry acceptable, or should UX spec the disable case too?

2. Default button. The call passes aDefaultButtonIndex = 1, so Cancel is the default/focused button, and I kept that. Comment 51 lists Cancel as CTA 1, which I read as consistent, but it doesn't actually say. Confirm Cancel should stay the default?

3. Whether "history" is the right scope. This is the one I'd most like a second opinion on. The approved body says "Your existing browsing history won't be deleted." But bug 2054590 — including comment 7 and the original report — shows users are confused about cache, cookies and site data just as much as history; that reporter's complaint was specifically about "Temporary cached files and pages" persisting. Someone reading this new dialog could still reasonably conclude their cache was wiped.

Saying "your existing browsing data won't be deleted" would cover both, and matches how emz described the actual behaviour in bug 2054590 comment 5 and comment 8 (permanent PBM doesn't touch normal-browsing data at all, and doesn't consult the clear-on-shutdown category selection). I did not make that change, because rewriting UX-approved copy unilaterally is what stalled this bug the first time. Worth taking back to UXREQ-370, or keep this history-specific and handle the broader confusion separately?

Happy to update the patch for any of these.