User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1b2pre) Gecko/20081120 Minefield/3.1b2pre Build Identifier: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1b2pre) Gecko/20081120 Minefield/3.1b2pre In the Tools -> Clear Recent History dialog, clicking (unchecking) "Download List" and then clicking it again leads to a checked but inactive (grey) checkbox. The download history is cleared. The checkbox stays inactive and unresponsive even after a restart and several downloads. Reproducible: Didn't try Steps to Reproduce: 1. Go to Tools -> Clear Recent History 2. Uncheck "Download List" 3. Click on "Download List" again

Please try in Safe Mode. Read http://new.quality.mozilla.org/bug-writing-guidelines. I think I saw this somewhere.

Problem still appears in save mode. Additional observation: When in the state described above ("Download list" checked and inactive), unchecking the item above "Visited Pages" reactivates "Download list". Checking "Visited Pages" again inactivates "Download list".

I can reproduce this on OS X, Windows and Linux (using today's Minefield nightly on OS X and yesterday's Minefield nightly on Windows and Linux). No idea about the cause, though.

Regarding Comment 2: I believe this is intended behavior. The only time the checkbox will not be checked and inactive is when the "Visited Pages" box is unchecked. A while back they changed the UI so that if you have "Visited Pages" check the assumption is you want to remove your Downloads as well (at least that was the way it was in the UI previously)

This cannot be the intended behavior. While recent testing I accidentally deleted my whole download list. This is definitely a dataloss bug. Deactivating the "Download List" item when checking the "Visited Pages" checkbox doesn't make sense at all. Both entries handling totally different data. This regressed between Firefox 2.0.0.x and Firefox 3.0.x.

Initially the behavior was been changed by bug 431729. But it's not the real cause of this regression. There was a change again between the builds 08110504 and 08110604. So the patch on bug 453440 has been caused this regression. Until the build from 081105 we had following structure: [ ] Browsing History [ ] Download History And it has been changed to: [ ] Visited Pages [ ] Download List Now that we have a flat structure, the entry "Download List" should not be modified when checking/unchecking "Visted Pages".

This is indeed the intended behavior, per bug 431729. (Bug 432724 exists to cover an inconsistency in the prefs UI.)

Though actually, I'd like to know why these were tied in the first place. I don't know the reason and can't find the justification anywhere.

I suppose it was decided to just use the nsINavHistory notifications in bug 251337, and then in bug 431729 it was decided that we wanted to tie the two histories completely because otherwise download entries for the cleared history items would never expire on their own. There are alternative ways to fix that that preserve the ability to clear each item separately, though. We could take attachment 318966 [details] [diff] [review] and schedule periodic cleanups of download entries that don't depend on history expiration.

The following comment has been written before I ran into a mid-air collision... Even when this bug has been closed as invalid now, I still strongly hold that the current UI is completely senseless and lead definitely to dataloss (as what I have experienced some minutes ago). Re-adding the dataloss keyword. Users who have disabled all checkboxes for this dialog under the preferences and choose "Tools|Clear Recent History" at a later time will not notice that the "Download List" checkbox gets selected because it's getting grayed-out in the same step. And further I still don't see any connection between visited pages and downloads. Both are totally independent and should also be handled that way.

This bug isn't about a UI issue - you shouldn't confuse it with bug 432724.

This decision was made in bug 251337 (see bug 251337 comment 25). The rational is that download history is history, and if a user wants to clear the fact that they visited somewhere, we don't actually clear it if we just clear downloads. Downloads keep track of where you downloaded them from, as well as referring page for the download. Because of this, I think this bug should be marked as WONTFIX.

(In reply to comment #12) > This decision was made in bug 251337 (see bug 251337 comment 25). It's quite likely that there's some IRC or in-person context I'm missing, but it's not clear from the comments in that bug that the tradeoff was being made explicitly (there's no mention in the bug that that change will make it impossible to only clear history and not downloads). > if a user wants to clear the fact that they visited somewhere, we don't > actually clear it if we just clear downloads. (I'm assuming you meant "if we don't clear downloads".) I think that is a valid argument; there's definitely room for confusion there if the user doesn't realize the link between them. But I don't think it necessarily follows that the best solution is to remove the user's ability to clear them independently. A possible alternate solution would be to somehow offer a strong reminder that downloads also contain "history" when you're only clearing history, for example. I understand that that kind of solution would introduce implementation complexity (i.e. need to schedule separate download expiration, changes to the sanitize dialog), but I also think that there might be better solutions, including perhaps "don't address that problem at all and just take attachment 318966 [details] [diff] [review]". If someone is really intent on clearing their tracks, aren't they're going to be checking the "clear download history" checkbox anyways?

Don't think this is WONTFIX, but I also don't think it blocks. We backed into this design because of the complexity of splitting things out, but I fundamentally agree with Gavin; we have checkboxes for history and downloads, and if someone wants to delete them both, they can delete them both. If we don't think that we should allow users to delete one and not the other, we should make the entry "Visited Pages and Downloads" and have a single checkbox. While I recognize that downloads are a form of history, it's no longer the case that we have a single option for "History" - the new dialog clearly illustrates what aspects of a user's history we retain, and all the subelements of history that can be deleted.

I agree with Gavin and Beltzner: ideally we have independently operating check boxes. Visited pages and downloads are just two components of a broader range of things that can be collectively considered "history."

Gavin, is that the right way we wanna go?

Comment on attachment 364752 [details] [diff] [review] patch v1.0 That's only part of the solution. We also need to fix the backend per my second paragraph in comment 9.

Thanks Gavin. I don't know if I really wanna do more on this part but that raises a question to Alex in either way. Alex, will this bug be fixed by the upcoming work for bug 480169?

Bug 480169 doesn't touch this at all, even though the UI implies that it does. I'll comment there.

I believe it is rather important that when a user is clearing browsing History, Firefox do not automatically remove his download history in the process. This will result in unintended data-loss. If he wants to remove both, he can choose to both options. In Firefox 3.5 Beta 4, Clear Recent history also have a option called Browsing & Download History. I believe that shouldn't be the way to clear history. I think Browsing and download history should be cleared independently from each other.

Everyone agrees that independent controls is ideal, we just need to get it implemented.

could this patch to this bug to done before Firefox 3.5 is released to the public?

Sorry for reposting, What I meant is Could this bug be fixed by the time Firefox 3.5 is released? I just patched my Firefox 3.5 beta 4 to the 3.5 preview. Clear recent history option box still have the option to clear both Search & download history at the same time. I believe, the UI should change after this bug has been fixed.

Jason: Short answer is "no", but the long answer is that the patch in this bug is not ready for users. It has been minused for review. Additionally, we're code frozen for Firefox 3.5 and have already produced release candidates.

Something I have been wanting to ask you guys. let's say you finish fixing this bug and Firefox 3.5 has been released and Firefox 3.6 is on its beta. Will you guys land this patch on Firefox 3.5 as a new feature or land only on Firefox 3.6?

We can't really land changes in 3.5.x that would change the text people see, since it would involve translating that text into all 75+ languages that Firefox ships in. But we always need people testing the new cutting edge development versions, so if that's something you would like to help with, it's also the first place you would see this patch land. You can find the Nightly Builds (which will auto update every night, perhaps unsurprisingly) here: http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/latest-mozilla-central/ To be clear, the patch hasn't landed there either, but when it's ready, that's where you'll find it. :)

Let me state that i reported a bug and was classified duplicate in Bug 505055. Upon reading this bug report i realized 2 things: 1] the aforementioned bug addresses the 3.X.X variant where the click button for download was indented below history checkbox in the tools>options>dialog box as ascribed in comment #6, whereby at times the subsequent use makes the download checkbox becomes grayed out when FF is closed and dialog box appears to confirm action ( and showing the download checkbox as marked even when it WAS NOT checked) and, 2] Bug 505055 addresses this issue concerning the already released 3.5.X variant, whereby the history AND download have separate entries. Just selecting History checkbox but NOT the download checkbox still produces the SAME issue ascribed in this Bug 465995, therefore, the question is: Does this Bug 465995 article states that the following attachment (patch v1.0) hereto addresses this issue and should be applied, or is the next update to 3.5.X variant will provide a fix to this issue? Note: I re-produced this action in 3.5.1 and the result was the same, ISSUE NOT RESOLVED. I do want the History cleared BUT NOT the Download cleared (was UNchecked). That was not what occurred, instead all download listings were cleared/erased (just click Tools>Downloads>download box appears EMPTY) If this was the intended purpose, then forgive my commenting here, otherwise please clarify my question and any other comment as deemed useful to this issue. Thank You. Suny

Bug 431286 illustrates that Firefox already recognizes the distinction between downloads and history, and it is in fact possible to delete them separately (albeit not from the CRH dialog). I think this is dependent (or at least will be fixed) by the proposed "Downloads" category in places, although I'm not sure what bug (or if there is a bug) that is.

(In reply to comment #30) > I think this is dependent (or at least will be fixed) by the proposed > "Downloads" category in places, although I'm not sure what bug (or if there is > a bug) that is. Bug 402231?

Hi, I am reported of bug 540559, which was marked duplicate, HOWEVER, it is not by 100%! 540559 even is a little extension of the basic problem, namely the workaround. There *IS* a workaround, but even this workaround does NOT work correctly. I'll repeat from my report: Current (ugly) workaround is: - Tools->Options->Privacy - Minefield will ... "Use custom settings for history" - [x]Clear history when Minefield closes In 'Settings', ONLY check "Browsing history". YOU SEE: there ARE two independently selectable checkboxes! But I tried with "Browsing history" checked and nothing else, and lo' and behold, my entire Download history was GONE after restarting the browser!!! So there's even more malfunction lurking inside that ol' chap...

(In reply to comment #33) > - Tools->Options->Privacy > - Minefield will ... "Use custom settings for history" > - [x]Clear history when Minefield closes > In 'Settings', ONLY check "Browsing history". > > YOU SEE: there ARE two independently selectable checkboxes! > But I tried with "Browsing history" checked and nothing else, and lo' and > behold, my entire Download history was GONE after restarting the browser!!! > So there's even more malfunction lurking inside that ol' chap... This is addressed by bug 432724.

Indeed. Thanks for the pointer!

...however, the only one that understood the matter from user's side, is fred in comment #3 from bug 432724. It's insane to apply for an interdependency if the majority of users wants to *in*dependently select Browsing and Download history, i. e. NOT be forced to purge both at a time. Hence, "bug" 432724 should be 'INVALID'.

Bug 432724 and bug 465995 do not agree with each other. Bug 432724 applies for interdependency of download and browsing history while bug 465995 applied for independent of download and browsing history. Bug 432724 should be marked as invalid as it supports the continuation of the current design that makes download history part of browsing history. When users want to clear browsing history, he may not want to clear download history (or the other around) this will caused unintended (and unexpected) dataloss. Bug 465995 aims to avoid this. Hence in order to avoid confusion in bugzilla, bug 432724 should be mark as INVALID.

Can this be fixed in time for Firefox 4? Unwanted Data loss is something that should be avoided and Firefox 4 having a newer UI should have a newer Clear Recent History Dialogue.

Whew! Getting around these "bug" trees is a trip lol And so we come full circle and learned the many pieces of our English language, picked the words that make history go round and round and round.... Yep, Mozilla got all the facts in and the verdict is in: We'll get a separate browser history and download history button that when checked will perform the action the USER specifically selected. Hurray! This is the spirit of Mozilla: to allow USERS to utilize the "Options" as like the "Control Panel". Hell, why not? Many users are familiar with control panel in windows or macs or Linux. Greater selectivity, functions, and settings can be done within the "options" dialog box. (I know, a coding nightmare, lol) Glad to hear that the issue is with the code, needing to disengage the history and download; making it Independent of each other. Problem solved, right?

Awaiting the arrival of the next best: FF4 (coming soon to PCs everywhere!) So, Don't Let Me Down! (As said by the cowboy inside a bar in "Back To The Future" III (3), if ya seen it ya can remember how he's said it lmao)