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)
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
Comment 1•15 years ago
|
||
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
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?
Comment 5•15 years ago
|
||
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.
Reporter | ||
Comment 10•15 years ago
|
||
Reporter | ||
Comment 11•15 years ago
|
||
Reporter | ||
Comment 12•15 years ago
|
||
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.
Comment 13•15 years ago
|
||
I can reproduce this using the steps in comment #12. There is definitely some sort of browsing information being stored.
Comment 14•15 years ago
|
||
(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.
Reporter | ||
Comment 15•15 years ago
|
||
(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.
Comment 16•15 years ago
|
||
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?
Comment 17•15 years ago
|
||
(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
Comment 18•15 years ago
|
||
Duplicate: bug 443651.
You need to log in
before you can comment on or make changes to this bug.
Description
•