History sidebar and Places->Show All History recently stopped showing the download history, regression-range: Works: 10-27-2008, Broken: 10-28-2008. Looks like the places fsync stuff may have done that.

Just to comment on the new behavior, I think it's a welcome change. As now when users clear their download history either manually or thru CPD [Clear private data], they don't have to also purge their browsing history of these files as well. Unless the Download manager db already maintains a link between its records and ones in the Places db, and when cleared by either method, removes them from both dbs? I don't know if we're going to go down the 'we can add a pref to turn this behavior off' road but I think most would agree download history belongs only in the download manager.

Noah see bug 431286 about the download db clearing, clearing history clears downloads, clearing downloads doesn't clear it from history.

i think that's wanted, see bug 412217 download history should not be mixed up with browsing history

(In reply to comment #3) huh? bug 412217 comment 10 (afaict) is saying that it should show up in places just not in the awesomebar, and this is what has been happening pre-3.1beta2. Also see bug 431286 comment 10 that this was unintended. Also this would be really weird UI, that download history is dependent on browsing history (i.e. clearing browsing history clears downloads), but doesn't show up in the actual history. Finally from my testing it seems that the db is recording the downloads, just something is preventing it from actually showing up in places. If I use an October 28th build, make a few downloads, then with the same profile open an October 27th build, those downloads show up.

we should have a "downloads" container in the Library for them, and this is asked in other bugs (and requires a way to query based on transition type), mixing up download visits with user visits makes no sense imho.

Can someone actually boil this down to a use case so I can get a sense of what used to and is no longer happening? We used to have history visits for the URI of a file download in the History root of the Library as well as in the Download manager?

The main reason I think this should block is the privacy issue when someone downloads, say something.wmv, then wants to get rid of it so he removes it from his downloads. He has no idea that it still exists in history (which if you'll open the same profile pre-October 28, it'll show up), namely because it _doesn't_ show up in _his_ history, even though it's in the history db! So 1) he/she effectively has now way of getting rid of a _single_ download, 2) he/she doesn't even no it's still there! This is besides the confusion of ui, that deleting history will delete downloads even though the two are maintained separately, but I think the privacy issue is real.

oh, and (in reply to comment #6) yes they used to show up (since ff3, not before) in Places history as well as the download manager. see bug 431286

I agree with the privacy concern, but that requires directly reading of the db, so we would have privacy concerns for embed visits too, since them are not shown in the UI. hwv most likely that is caused by query rewriting using NOT IN (0,4,7) instead of NOT IN (0,4).

(In reply to comment #9) IMHO this isn't a very good argument. Embed visits, while they may be revealing, aren't as accessible as downloads and they aren't a result of a clear action by the user. Furthermore, the downloads are being clearly recorded with ui in the download manager, when someone removes it from the only ui it exists in, he expects it to be completely removed. Finally, just opening the profile in a previous firefox/minefield brings up the download data, so no database reading tools are really necessary.

Regardless of the merits of the feature, we need to definitively understand why this is occurring, as it certainly is a regression from Fx3 behavior. Assigning to Marco to make sure we understand the cause of the problem. That said, I agree that this feature could use re-evaluation. Marking ui-wanted and cc'ing Faaborg to get some analysis on the relevancy of this feature. Marking blocking because we need an explicit decision for one way or the other.

as i said, we are filtering out (0,4,7) transition types and visit_count = 0, to show downloads we have to change that.

Comment on attachment 347759 [details] [diff] [review] patch + test dietrich found a minor glitch, new patch coming

Comment on attachment 347970 [details] [diff] [review] patch v1.1 r=me

ok so, do we want to take this? and if yes, for b2?

Comment on attachment 347970 [details] [diff] [review] patch v1.1 requesting ui-review per c#16 This exposes downloads into the Places window (again; we shipped with this UI in 3.0)

Comment on attachment 347970 [details] [diff] [review] patch v1.1 Yup, let's start by restoring the Firefox 3 behaviour. We can think more about whether or not they should be in their own section ("Downloads") at another time. I think there's already a bug on that.

pushed to trunk http://hg.mozilla.org/mozilla-central/rev/cdcd973bd503

pushed to 1.9.1 branch: http://hg.mozilla.org/releases/mozilla-1.9.1/rev/6fb6b8b38057

verified with Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1b3pre) Gecko/20090127 Shiretoko/3.1b3pre