Closed Bug 504576 Opened 15 years ago Closed 15 years ago

Clearing private data does not affect frecency information for bookmarks

Categories

(Firefox :: Address Bar, defect)

3.0 Branch
x86
Windows XP
defect
Not set
normal

Tracking

()

RESOLVED DUPLICATE of bug 450502

People

(Reporter: bugzilla, Unassigned)

Details

Attachments

(6 files)

User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.0.11) Gecko/2009060215 Firefox/3.0.11 Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.0.11) Gecko/2009060215 Firefox/3.0.11 Clearing private data should have the ability to clear all usage information but there appears to be no way for me to clear the frecency information associated with bookmarks. This information is retrievable, and feeds into the URL bar. Maybe a potential solution is to add a checkbox in the Private Data/Settings section for "Bookmark Usage History". (Most folks won't understand a word like "frecency".) Another potential solution would be an option to not collect frecency information in the first place. Having this option hidden in about:config would be fine. I think a lot of people are confused by this feature, and they end up turning the URL bar off, which of course does not turn off the frecency data collection (only the display of this information. I was surprised to not find a bug report on this already. See: http://www.labnol.org/software/browsers/prevent-firefox-showing-bookmarks-address-location-bar/3636/ http://fixunix.com/mozilla/442333-url-bar-history-toggle-off.html Reproducible: Always Steps to Reproduce: 1. Use a bookmark frequently 2. Close the browser (with "clear private data" 3. Re-open the browser, drop down the URL list Actual Results: Bookmarks are ordered by frecency Expected Results: No bookmarks appear unless I use some bookmarks since re-opening the browser or type in the URL bar
Bookmarks always appear in the location bar unless you choose to hide them via the pref. Clearing history does in fact reset the frecencies of bookmarks, but not such that they'll disappear from location bar searches. That's how the location bar is designed to work. If you'd like a privacy checkbox for "collect history but don't collect frecency", or if you think bookmarks should be hidden from location bar searches after clearing history even if the user's pref is to show bookmarks in location bar searches, please file separate bugs, but they will probably be wontfixed. I'm marking this one invalid since clearing private data does in fact affect bookmark frecencies.
Status: UNCONFIRMED → RESOLVED
Closed: 15 years ago
Resolution: --- → INVALID
(In reply to comment #1) > Bookmarks always appear in the location bar unless you choose to hide them via > the pref. Clearing history does in fact reset the frecencies of bookmarks, but > not such that they'll disappear from location bar searches. That's how the > location bar is designed to work. Clearing history does NOT clear frecency
Attached image Screenshot of location bar (deleted) —
Just a clarification: I am not referring to the location bar *search*, or proposing any changes to the *search* I am referring to the bookmarks I see when I drop down the list when the browser is opened fresh In the attached screenshot, that's the button at the far right with a tiny down arrow Looking at the dropdown list, it is clear that *something* is saved even though I clear private data. Maybe it's not frecency - I'm not a FF expert - but then what is it?
Clearing frecency doesn't mean bookmarks are not shown in the location bar.
What would be helpful would be if someone could let me know, or point me to something that tells me how those bookmarks are selected. Again, this is about the list I can drop down after a clean start of FF, not the search feature.
Attached image Locationbar dropdown in new FF profile (deleted) —
Attached image Privacy selection for FF profile (deleted) —
I realized this was not very clear. See the screenshots. Somehow FF remembers which website I've been at most recently (unrelated to bookmarking). 1. Create a new profile, change prefs to privacy (see screenshot) 2. Bookmark some websites (see screenshot) 3. Close FF, re-open FF, visit the website that's third on the list 4. Close FF, re-open FF, drop down the list Actual behavior The list is reordered by visiting a website Expected behavior The list is not reordered by visiting a website Somehow somewhere there is some browsing information that's not cleared. Maybe not frecency (that was just my guess), but there is something. Hope this helps.
I can reproduce this using the steps in comment #12. There is definitely some sort of browsing information being stored.
(In reply to comment #12) Ah, sorry for misunderstanding. I believe you're seeing bug 450502, which causes frecencies to not be reset, exactly as you say. It's been fixed in 3.5, so could you try it and report back? It should definitely work.
(In reply to comment #14) > (In reply to comment #12) > Ah, sorry for misunderstanding. I believe you're seeing bug 450502, which > causes frecencies to not be reset, exactly as you say. It's been fixed in 3.5, > so could you try it and report back? It should definitely work. Yay, it's resolved! I don't think I was very clear - sorry about that.
I'm still seeing this in 3.5. Looking at my moz_places table, there are a few entries that have a visit count greater than 0, and some of these have a frecency that is -2 or -3 (rather than -1). Is this behavior correct?
(In reply to comment #15) > Yay, it's resolved! I don't think I was very clear - sorry about that. Thanks for testing it. (In reply to comment #16) > I'm still seeing this in 3.5. Looking at my moz_places table, there are a few > entries that have a visit count greater than 0, and some of these have a > frecency that is -2 or -3 (rather than -1). Is this behavior correct? Negative frecencies are expected and indicate that they've been "reset" and should be recalculated.
Resolution: INVALID → DUPLICATE
Version: unspecified → 3.0 Branch
Duplicate: bug 443651.
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: