847627 - The clear Downloads History at shutdown option should be updated
Closed Bug 847627 Opened 12 years ago Closed 12 years ago

The clear Downloads History at shutdown option should be updated

Categories

(Firefox :: Downloads Panel, defect)

defect
Not set
normal

Tracking

()

RESOLVED FIXED
Firefox 22
Tracking Status
firefox19 --- unaffected
firefox20 + wontfix
firefox21 + verified
firefox22 + verified
relnote-firefox --- 20+

People

(Reporter: mak, Assigned: mak)

References

Details

Attachments

(2 files, 1 obsolete file)

For the downloads panel it doesn't make any sense, we should probably change it to "Browsing and download history" to cope with the privacy pane if useToolkitUI is false.
For Firefox 20/21, Mak - can we set "Download History" as an inactive widget whose value mirrors the "Browsing History" setting? https://bugzilla.mozilla.org/show_bug.cgi?id=850207#c6 is a good option for 20/21 as well, but has too much possible l10n impact. (In reply to Marco Bonardo [:mak] from comment #0) > For the downloads panel it doesn't make any sense, we should probably change > it to "Browsing and download history" to cope with the privacy pane if > useToolkitUI is false. Please land this in the next 2 weeks, so that the string is localized properly in 22.
Assignee: nobody → mak77
For reference, to get to this panel you have to go to Firefox Prefs > Privacy > Firefox Will > Use custom settings > clear history when firefox closes > Settings
(In reply to Alex Keybl [:akeybl] from comment #2) > For Firefox 20/21, Mak - can we set "Download History" as an inactive widget > whose value mirrors the "Browsing History" setting? then selecting download history would clear browsing history, that looks even worse. Unless by inactive you meant not selectable by the user? > (In reply to Marco Bonardo [:mak] from comment #0) > Please land this in the next 2 weeks, so that the string is localized > properly in 22. ok
Status: NEW → ASSIGNED
(In reply to Marco Bonardo [:mak] from comment #4) > (In reply to Alex Keybl [:akeybl] from comment #2) > > For Firefox 20/21, Mak - can we set "Download History" as an inactive widget > > whose value mirrors the "Browsing History" setting? > > then selecting download history would clear browsing history, that looks > even worse. Unless by inactive you meant not selectable by the user? Correct - that's what I meant. The user can enable/disable Clear Browsing History, but can't manually enable/disable Clear Download History. Clear Download History's checkbox would be tied to Clear Browsing History.
relnote-firefox: --- → ?
Blocks: 850207
No longer blocks: 850207
This patch implements Alex suggestion to disable Download History item and link it to the Browsing History value, it also supports the useToolkitUI preference, so that it acts only if the Downloads Panel feature is enabled. I think we could land this version on trunk and branches, then make a part 2 patch for trunk. The trunk patch will instead hide the Download History item and relabel Browsing History to Browsing and Download History. It will still have to support useToolkitUI for now, since we didn't release any version with the new Panel yet.
Attachment #725384 - Flags: review?(gavin.sharp)
fwiw, I'm re-evaluating trunk, since the 2 history are unified from a long time also in the privacy options, we can probably avoid handling useToolkitUI there.
Comment on attachment 725384 [details] [diff] [review] Aurora/Beta patch ugh, sanitize.xul already has a Browsing & Download history entry that we can reuse across all branches!
Attachment #725384 - Flags: review?(gavin.sharp)
Reusing strings for different contexts can be a L10n problem, as in some languages they might need to differ based on context.
Comment on attachment 725384 [details] [diff] [review] Aurora/Beta patch nevermind, while we already have the string, we should increase the width of the dialog, that means bumping the width entity names, so we still cannot use it on branches.
Attachment #725384 - Flags: review?(gavin.sharp)
This is on top of the first patch, instead of having 2 separate items it has just one that controls both history and downloads. The dialog width has been increased, both Clear History on Shutdown and Clear Recent History will thus be a bit larger.
Attachment #725395 - Flags: review?(gavin.sharp)
to be sure some test didn't pass unnoticed https://tbpl.mozilla.org/?tree=Try&rev=6771a66b0abc
Comment on attachment 725395 [details] [diff] [review] part 2, unify Browsing and Download history item Review of attachment 725395 [details] [diff] [review]: ----------------------------------------------------------------- ::: browser/locales/en-US/chrome/browser/sanitize.dtd @@ +53,5 @@ > that appears when "Time range to clear" is set to "Everything". See UI > mockup at bug 480169 --> > <!ENTITY sanitizeEverythingUndoWarning "This action cannot be undone."> > > +<!-- LOCALIZATION NOTE (dialog.widths): width of the Clear Recent History and self comment: typo, should be a 2, not a s.
(In reply to Robert Kaiser (:kairo@mozilla.com) from comment #10) > Reusing strings for different contexts can be a L10n problem, as in some > languages they might need to differ based on context. We already reuse all of these strings across the 2 sanitize dialogs, so I'm not doing anything new here. I also don't think we should do differently since the context is basically the same (checkboxes stating what to clear).
Attachment #725384 - Flags: review?(gavin.sharp) → review+
I guess I'm also a bit confused about how we got into this state. Apparently we've combined these items in the "clear recent history" dialog for a long time now (since bug 480169, apparently?). Did we just forget this copy of sanitize.xul all this time?
(In reply to :Gavin Sharp (use gavin@gavinsharp.com for email) from comment #16) > I guess I'm also a bit confused about how we got into this state. Apparently > we've combined these items in the "clear recent history" dialog for a long > time now (since bug 480169, apparently?). Did we just forget this copy of > sanitize.xul all this time? Since we proceeded in small steps it's very likely. Download history has basically been duped between Places and the Download Manager, from a long time but users did not figure that history was keeping their downloads history until we released the Downloads Panel that made that extremely clear. Most users just thought an empty Download Manager window meant that download history was gone, so the 2 separated options made sense to them since checking download history was having a direct effect on the product (empty manager). Just a few filed bugs complaining the downloads were still in the Library even after that. Now that the Panel put the Library downloads view in front of users, doesn't make more sense to clean up those separately (we have bug 838681 to investigate eventual use-cases) and users started complaining that clearing download history doesn't clear the Library downloads view, thus this bug.
Also note with the old DM window there was a very good reason to clear downloads without touching history, that window becomes very slow to open with many downloads.
So if I understand the current status quo correctly, if I don't want to keep downloads, I have to either delete them manually every time I close the browser, or if I want do have them deleted automatically, I will have to also lose all of my browsing history? Isn't that totally braindead? I really hope bug 838681 gets fixed together with this.
(In reply to khagaroth from comment #19) > if I don't want to keep downloads, I have to either delete them manually every time I > close the browser, or if I want do have them deleted automatically, I will have to > also lose all of my browsing history? That's correct. Clearing downloads removes downloaded file entries, not downloaded files on your computer, so the interest of doing that is to save low space in your Firefox profile or prevent someone else that has access to your OS user account (not recommended) to see in your browser what you've downloaded (he can still see them on your HD).
First part pushed, will ask for approval as soon as the tree confirms green, likely tomorrow considering the current time. https://hg.mozilla.org/integration/mozilla-inbound/rev/34bf1e07b8d3 The second part will only be pushed to central since it involves string changes.
Whiteboard: [leave open]
Target Milestone: --- → Firefox 22
Unfortunately we're past the timeframe for accepting a fix here since we'll be building our second-to-last beta EOD today and our last beta is only for security fixes and backouts that put us to a known-good state with regards to quality/stability. So this can get nommed/uplifted to Aurora but we won't be able to take it in FF20.
Comment on attachment 725384 [details] [diff] [review] Aurora/Beta patch [Approval Request Comment] Bug caused by (feature/regressing bug #): downloads panel feature User impact if declined: Clear Download History on shutdown dialog is confusing Testing completed (on m-c, etc.): m-i Risk to taking this patch (and alternatives if risky): it's limited in scope to a small portion of the sanitize dialog String or UUID changes made by this patch: none
Attachment #725384 - Flags: approval-mozilla-aurora?
Comment on attachment 725395 [details] [diff] [review] part 2, unify Browsing and Download history item Seems like you could get rid of gSanitizeDialog.init in favor of just calling onClearHistoryChanged directly. Can we get rid of privacy.clearOnShutdown.downloads entirely? I'm not sure how it's useful anymore (or why we should keep its value in sync with privacy.clearOnShutdown.history).
Attachment #725395 - Flags: review?(gavin.sharp) → review+
(In reply to :Gavin Sharp (use gavin@gavinsharp.com for email) from comment #24) > Seems like you could get rid of gSanitizeDialog.init in favor of just > calling onClearHistoryChanged directly. yes, I kept it for "future", but doesn't make sense for now. > Can we get rid of privacy.clearOnShutdown.downloads entirely? I'm not sure > how it's useful anymore (or why we should keep its value in sync with > privacy.clearOnShutdown.history). Well, we still support useToolkitUI, and if you set it to true downloads are retained at shutdown, thus we should still clean them up in that case. And that's why I think it's too early to get rid of it. Surely once we remove that fallback it will be feasible.
Removed init()
Attachment #725395 - Attachment is obsolete: true
Status: ASSIGNED → RESOLVED
Closed: 12 years ago
Resolution: --- → FIXED
Comment on attachment 725384 [details] [diff] [review] Aurora/Beta patch Its a Bug in the new downloads panel feature. This patch unifies Browsing and Download history item to avoid confusion on clear download history . Low risk patch & risk being limited to these new sanitized dialog. Adding qawanted/verifyme to help with verification here.Comment #5 should be a good reference of how this should be working. Thanks !
Attachment #725384 - Flags: approval-mozilla-aurora? → approval-mozilla-aurora+
Keywords: qawanted, verifyme
Simona, as QA owner for this feature can you please make sure this is tested? It landed in mozilla-central today so it should be in tomorrow's Nightly. Assuming it lands on mozilla-aurora today (it has approval) I would expect it to be in tomorrow's Aurora. You'll need to test this on both branches. Thank you.
Keywords: qawanted
QA Contact: simona.marcu
Thanks for the push Ryan.
Added a relnote to FF20 saying this is fixed in FF21
The 2 options "Browsing History" and "Download History" are still separated on the latest Aurora. Moreover, the option to clear the "Download History" can't be enabled. Is this expected in any way?
(In reply to Simona B [QA] from comment #35) > The 2 options "Browsing History" and "Download History" are still separated > on the latest Aurora. Moreover, the option to clear the "Download History" > can't be enabled. > > Is this expected in any way? Yes, and the Download History item checked state should match the Browsing History item.
It's probably too late to change, but, just in case it isn't, I would rather work around this (on the branches I mean) by a "generic" History label (we could take it from the History menu).
Verified as fixed on the latest Nightly, latest Aurora and Firefox 21 beta 1. As described in Comment 7 - on the latest Nightly, the option is updated to "Browsing and download history" and on the latest Beta and Aurora to "Browsing History" and "Download History" (the checked state matches). Verified on Windows 7, Ubuntu 12.04 and Mac OS X 10.8: Mozilla/5.0 (Windows NT 6.1; rv:21.0) Gecko/20100101 Firefox/21.0 (20130401192816) Mozilla/5.0 (Windows NT 6.1; rv:22.0) Gecko/20130401 Firefox/22.0 (20130401030817) Mozilla/5.0 (Windows NT 6.1; rv:21.0) Gecko/20130401 Firefox/21.0 (20130401042013) Mozilla/5.0 (X11; Linux i686; rv:22.0) Gecko/20130401 Firefox/22.0(20130401030817) Mozilla/5.0 (X11; Linux i686; rv:21.0) Gecko/20130401 Firefox/21.0(20130401042013) Mozilla/5.0 (X11; Linux i686; rv:21.0) Gecko/20100101 Firefox/21.0(20130401192816) Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:23.0) Gecko/20130402 Firefox/23.0 (20130402030843) Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:21.0) Gecko/20130401 Firefox/21.0 (20130401042013) Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:21.0) Gecko/20100101 Firefox/21.0 (20130401192816)
Other bugs with new download manager: If useToolkitUI is true in about:config, and the user use the old download manager, when .exe file was downloaded, the title of the old download manager disappears. Also when i click on the button "Clear List" in the Old Download Manager, this doesnt`t clear the history in Library - Downloads. Another problem is the very bad performance of the old download manager in Firefox 20 - it works very slow. In Firefox 19.0.2 it works better.
(In reply to programings from comment #40) > Other bugs with new download manager: please file separate bugs for issues, this is not the right place to report them. Thanks.
This is NOT a bug. The history and DL windows should remain separate. "all your eggs in one basket" comes to mind. People do a lot more DL'ing these days and many people I know like to have a separate window for DL's to have sitting on the desktop for when the browser is not open. A large window of combined history and downloads takes up too much space, and sits there displaying information the user doesn't need. For example-- when monitoring a DL there is zero need to see browsing history, and likewise, when looking for history items there is no need to see downloads. I for one have had to downgrade the version to keep the windows separate, please "undo" this "fix". It wasn't a bug at all to start with, it's merely a few users deciding what millions of people are supposed to do, rather than letting them have the option.
hi, thank you for your feedback, unfortunately options are very expensive to maintain for us, so we must take decisions based on what may satisfy most of our hundreds millions users. Unfortunately this means sometimes someone (like you) may be unhappy about some of the changes. We are currently in phase 2 of development of the new downloads experience, we are evaluating all of the incoming feedback and working on improvements. The fact the Library window takes some more pixels on its side is a weak reason for reverting the change, especially on today's widescreen monitors, though, if you are missing any functionality we are happy to listen about those.
(In reply to emil.locurado from comment #42) > This is NOT a bug. The history and DL windows should remain separate. "all > your eggs in one basket" comes to mind. People do a lot more DL'ing these > days and many people I know like to have a separate window for DL's to have > sitting on the desktop for when the browser is not open. A large window of > combined history and downloads takes up too much space, and sits there > displaying information the user doesn't need. For example-- when monitoring > a DL there is zero need to see browsing history, and likewise, when looking > for history items there is no need to see downloads. > I for one have had to downgrade the version to keep the windows separate, > please "undo" this "fix". It wasn't a bug at all to start with, it's merely > a few users deciding what millions of people are supposed to do, rather than > letting them have the option. Completely Agree. Starting with FF20 I set useToolkitUI to True to partially solve that big mess. Full-size-window download manager is also IMO a waste of space and harder to manage ongoing items.
In the Settings for "Clear history when firefox closes", why is the button "Download history" greyed out (can not edit)? Why must it be equal to the "Browsing history" button??? I need to clear the download history and keep the browsing history, but I can't do it automatically, while Firefox provides the buttons to do it by hand. This has no sense to me...
Depends on: 873665
(In reply to bahamut00 from comment #45) > why is the button "Download history" greyed out (can not edit)? It won't show up in Firefox 22.0. > I need to clear the download history and keep the browsing history It's bug 873665. As a workaround, you can clear the download history manually in the Library window.
(In reply to Scoobidiver from comment #46) > (In reply to bahamut00 from comment #45) > > why is the button "Download history" greyed out (can not edit)? > It won't show up in Firefox 22.0. Please don't make this mistake. Keep separate automatic clearing options. I agree with arguments in bug report 873665. > > I need to clear the download history and keep the browsing history > It's bug 873665. As a workaround, you can clear the download history > manually in the Library window. I don't want to do it by hand. I wan't firefox to do it for me automatically. If I can do it by hand, then Firefox should be able to do it for me. As for now this new "feature" is a regression. Please stop making Firefox users life worse.
(In reply to bahamut00 from comment #47) > Keep separate automatic clearing options. If you want that, please vote for bug 873665. If you want to clear the download history (downloaded files have never been deleted) for privacy reasons (don't want someone using your computer to see your download history), see https://support.mozilla.org/kb/how-do-i-share-firefox-between-people-on-computer
(In reply to Scoobidiver from comment #48) > (In reply to bahamut00 from comment #47) > > Keep separate automatic clearing options. > If you want that, please vote for bug 873665. Done. However I am wondering if votes on the bug tracking system makes any difference in the development process of Firefox. Standard users won't vote here, and will express its disappointment by other means (including saying nothing and/or going to another internet browser). > If you want to clear the download history (downloaded files have never been > deleted) for privacy reasons (don't want someone using your computer to see > your download history), see > https://support.mozilla.org/kb/how-do-i-share-firefox-between-people-on- > computer Not very helpful / nothing new (I am redirected to the French translation). Note that I can invoke privacy reasons without sharing my computer.
please, use a private browsing window when browsing or downloading uncomfortable stuff. That's the only working way to keep your privacy safe, clearing part of what you did is not going to save you, it's just apparent (but unreal) privacy.
* please can someone answer my first remark: if I can clear the download "list" by hand, why firefox couldn't do it automatically? Whatever this clearing is perfect or not, I don't care. Rephrase it differently if you want to suppress ambiguities. I just don't want this list to be filled with a 6-month old list of entries. For convenience, for privacy, whatever, I just want to keep it empty! The deep details of my browsing history are just another issue I do not discuss here. * in the past years firefox added fine clearing possibilities including "Forget about this site" and "Delete this page". There is also a "Remove from history" in the Library. Does this cleanly remove all references to the associated object in the history database? * you developers seem to have added a confusion between page browsing and file downloading. You probably merged all this internally under the same database. You make no difference anymore, but these are separate notions in the end-user mind.
bahamut000, this bug is fixed. If you want old features back or new features, please file one bug for each request.
(In reply to Scoobidiver from comment #52) > bahamut000, this bug is fixed. > If you want old features back or new features, please file one bug for each > request. What for? The bug 873665 was opened on this purpose and closed as wontfix. I tried for other issues, and my bug was closed-duplicate of the discussion which introduced the new feature. There seems to be no open-minded discussion possible, developers are deaf to users feedback and never accept undo their changes. There is actually no real follow-up of users feedback, every mean is likely to be redirected to /dev/null (do you read this: https://input.mozilla.org ? Do you make any summary from it?). With my bad experience on this topic, I am wondering who you are developing Firefox for. You or users?
What you don't seem to understand is that you introduced this new feature 2 months ago, but it is just reaching real users now. Maybe it is an old topic for you, but it not for the million of Firefox users. The real feedback is just starting, you can not state this topic is closed.
bahamut00, Bugzilla is not a forum. Once a fix is done the bug is closed, even if the fix raises issues. So please file new bugs for each request you want.
We listen to all of the feedback, that doesn't mean we should agree with all of it. We put a lot of efforts listening to users, but that's not always possible, I'm sorry, you may be hitting one of those cases, but be sure we are reading your opinions, and we think about them.
(In reply to Scoobidiver from comment #55) > bahamut00, Bugzilla is not a forum. Once a fix is done the bug is closed, > even if the fix raises issues. So please file new bugs for each request you > want. Let it be. Done in bug 876476.
I reported here a regression and here is a summary of how this was treated: - I tried to discuss here but I was answered this is not the place for discussion, - I was asked to vote for a bug report about this topic, but this bug was closed right after, - I was asked to open a new bug report, but no beginning of discussion started, - for completeness, I posted a feedback in the dedicated mozilla.org area, with no more success. Now, here are my personal feelings: there is no place for discussion at all. As software engineer, I feel important to report bugs and regressions. This one is a free regression with no technical nor security nor privacy reasons (on the contrary, my privacy is worse now, even if you don't want to understand it). Also, it lets firefox in an inconsistent shape. But now i am fed up of being the bad guy here and arguing in the void. So I close my bugzilla account and hope you will finally understand why firefox is loosing each day more and more users.
bahamut00, if you known how to treat hundreds of thousands of bugs with hundreds of developers, please open a thread in the developer group.
mass remove verifyme requests greater than 4 months old
Keywords: verifyme
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: