394133 - clearing private data zero out the visit_count for all remaining places

Status: RESOLVED WONTFIX

(Firefox :: Bookmarks & History, defect)

Description

[(not reading, please use [e-mail] instead)]

should clearing private data zero out the visit_count for a bookmarked place?

note, we only persist visit count for bookmarked places (as non bookmarked places would be removed from moz_places.

note, we use visit_count for the url bar autocomplete and it would also affect the order of items in the history sidebar, once you start visiting pages again so having the visit count might be useful, but it might be a privacy issue not to clear it.

comments?

Comment 1

[Dietrich Ayala (:dietrich)]

> so having the visit count might be useful, but it might be a privacy issue not
> to clear it.

i think the intent of clearing history via CPD is to remove all visits, not some visits, so not doing so would be a privacy issue. it might be worth having different levels of CPD (clean vs deep clean). explaining "useful vs non-useful visits" in a dialog will be a challenge. we'd have to make it very clear that the users' tracks have not been erased.

looking forward, we're going to need more granularity wrt to what gets cleared as we move forward with the "adaptive learning" autocomplete feature, etc.

Comment 2

[Jo Hermans]

isn't this bug 370644 ?

Comment 3

[Marco Bonardo [:mak]]

(In reply to comment #2)
> isn't this bug 370644 ?

similar, there are 2 items that are mantained in places: bookmarks (this bug) and places with annotations:EXPIRE_NEVER (part of that bug).

for clarity they could be unified though, since a single patch could solve both, Bug 370644 is more generic so i suggest marking this as a dupe and adding a comment there with the list of the items that will never get deleted from moz_places.

Comment 4

[(not reading, please use [e-mail] instead)]

for bug #394038, this will be fixed.

the reason we want it for that bug is that visit_count is used when calculating global frecency.

In ClearHistory(), after we call ExpireItems() and delete the dangling places with ExpireHistoryParanoid() call, I plan on doing something like this:

+  // for all renaming places, reset the frecency and visit_count
+  // XXX todo: once we add last_visit_date, reset that, too.
+  rv = connection->ExecuteSimpleSQL(NS_LITERAL_CSTRING(
+    "UPDATE moz_places SET frecency = -1, visit_count = 0"));
+  if (NS_FAILED(rv))
+    NS_WARNING("failed to recent frecency, visit_count");
+
+  // XXX todo
+  // recalc frecency for bookmarks?

Comment 5

[(not reading, please use [e-mail] instead)]

> for bug #394038, this will be fixed.

actually, this wont be fixed by that bug.

Instead, I'm purposefully *not* clearing visit_count because I'd actually like to use the old and out of date visit count for:

1)  breaking ties between places where frecencies are equal (which is likely to happen when frecency gets reset to -1 on migration or after clear all private data.

2)  for determining which places to recalculate first, on idle, 

note, on frecency recalculation, we will properly recalculate visit count.

details in bug #394038 and http://wiki.mozilla.org/User:Sspitzer/GlobalFrecency

But I'm arguing that this bug should be wontfix.  as side effect is places where we use visit_count (in the most visited places smart query and in the places organizer) may not always be correct.  I'll log a spin of bug about that.

Comment 6

[(not reading, please use [e-mail] instead)]

marking wontfix based on my own comments.

Comment 7

[Gervase Markham [:gerv]]

Bug 451915 - move Firefox/Places bugs to Firefox/Bookmarks and History. Remove all bugspam from this move by filtering for the string "places-to-b-and-h".

In Thunderbird 3.0b, you do that as follows:
Tools | Message Filters
Make sure the correct account is selected. Click "New"
Conditions: Body   contains   places-to-b-and-h
Change the action to "Delete Message".
Select "Manually Run" from the dropdown at the top.
Click OK.

Select the filter in the list, make sure "Inbox" is selected at the bottom, and click "Run Now". This should delete all the bugspam. You can then delete the filter.

Gerv

Comment 8

[Federico]

This bug got wontfixed, but looks like currently (I'm using Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.7) Gecko/20100106 Ubuntu/9.10 (karmic) Firefox/3.5.7) clearing recent history *does* clear bookmarks visit count thus resetting bookmarks frecency (all bookmarks will have the same frecency); at least, data shown in "Security/Privacy and history" tab of Ctrl+I are reset. 
I think that it would be useful to treat frecency separately, by adding another checkbox in the "clear recent history" details ("reset bookmarks visit count") or another preference in about:config to have bookmarks visit count not reset when you clear history (although in this manner to occasionally reset it you would have to change the preference, clear history and finally re-change the preference).