Closed Bug 400495 Opened 17 years ago Closed 16 years ago

Add "Clear List" button to download manager

Categories

(Toolkit :: Downloads API, defect)

Product:
Toolkit
Component:
Downloads API
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
VERIFIED FIXED
Milestone:
mozilla1.9

People

(Reporter: Mardak, Assigned: Mardak)

References

Details

(Keywords: regression)

Attachments

(2 files, 6 obsolete files)

screenshot of v2.1
49.69 KB, image/png
beltzner
: ui-review+
Details
v2.3
12.05 KB, patch
mconnor
: review+
mconnor
: ui-review+
mconnor
: approval1.9+
Details | Diff | Splinter Review 
Per bug 397655 mockups, there's a Clear List button.
Attached patch v1 (obsolete) — — Splinter Review 
Simple enough ;) Strings are set in the depends-on bug 391863.
Assignee: nobody → edilee
Status: NEW → ASSIGNED
Attachment #285570 - Flags: review?(comrade693+bmo)
Comment on attachment 285570 [details] [diff] [review]
v1

can you can the resizer while we are at it?  I don't think we technically need it anymore (how we open the window should already add it, but check).
Attachment #285570 - Flags: review?(comrade693+bmo) → review+
Attached patch v1.1 (obsolete) — — Splinter Review 
Yup. Removing the resizer results in the download manager still having its resizer.
Attachment #285570 - Attachment is obsolete: true
Attachment #285617 - Flags: approval1.9?
Comment on attachment 285617 [details] [diff] [review]
v1.1

defer for now until we decide if we're doing this.
Attachment #285617 - Flags: approval1.9?
I think this should definitely go ahead, but for a different reason. Currently "Clear list" is directly under the "Remove" option which IMO is very dangerous, if the user wants to remove just one item but accidentally slip they could wipe out their entire list. 

The context menu should really only be for options regarding one download in the list since you right click on one download to show the menu. The clear list action affects every download in the list so it should be placed in a different part of the UI.

But should the "clear list" action stay in the context menu, it really needs to be moved from where it is now, it is bunched against actions that affect a totally different portion of the list.
I vote for implementing "clear list" button somewhere near "Search" area or in the window title near maximize/minimize buttons, it is very inconvenient to use context menu, while 99% of all other actions in download manager are done with single mouse click.
I would also prefer having a "Clear List" button which would make one click cleaning possible.
Having a "Clean and Close" button would be nice too. See: https://addons.mozilla.org/en-US/firefox/addon/2608
Bump...Has this been approved or denied yet?

I think it's something extremely important to have as it's been in the Download Manager as long as Firefox has had a download manager.
We'll probably wait so long like users are waiting for icon view in GTK+ file picker...
Most users don't right click to bring up the context menu looking for extra functionality. This ends up them having lots of entries in the download manager.
Flags: blocking-firefox3?
Attached patch v1.2 (obsolete) — — Splinter Review 

        Attachment #300038 -
        Flags: review?

        Attachment #300038 -
        Attachment description: It adds Clear List button → v1.2

    
    

    
  
If it's not added to the bottom of the download manager, add it to "downloads" in the tools menu dropdown.  Include a "save files to" dialog there as well.


    
    

    
  
This does not block the final release of Firefox 3.
Flags: blocking-firefox3? → blocking-firefox3-

    
    

    
  
Usability bugs do not stop the release? I'm quite curious why...

    
    

    
  
I'm in the same camp as Jakub. I'm wondering why this was removed as blocking or not merged into trunk already. There's already a patch and i think if there is no clear list button in the download manage...that it will have a much bigger backlash than when the Home button was moved to the bookmark toolbar. It seems like a very simple patch (less than 3 lines of code) and it's a huge usability improvement for many users, so why not include it?

    
    

    
  
The button was removed by design (see the mockups in bug 397655) and the functionality exists on the context menu. Asserting that this is a usability bug doesn't make it blocking, nor does the fact that you'd like it returned.

Your feedback is appreciated, but it was decided (after a lot of design debate) that the function wasn't a primary use case for that window, and that the performance implications had been mitigated by chunking the results in the display, and that removing the button provided a less cluttered UI and prevented accidental dataloss from people clicking where an "OK" button is expected to be.

I didn't WONTFIX this bug because I'm willing to believe we'd reconsider, but it certainly isn't blocking.

    
    

    
  
You must know, that most of users (name them "newbies") doesn't know that some features are hidden in context menus (they need to SEE the features).

Also, left click is so... "default" so right click is almost forgot by some kind of people.

    
    

    
  
(In reply to comment #21)
> You must know, that most of users (name them "newbies") doesn't know that some
> features are hidden in context menus (they need to SEE the features).
> 
> Also, left click is so... "default" so right click is almost forgot by some
> kind of people.
> 

Again, agreed...So much so that Mac laptops don't even have a right mouse button (the mighty mouse really doesn't count). For the people using them, they're at even more of a disadvantage by not having clear list as a button.


    
    

    
  
To be sure, I'm not a newbie (reason I'm here), but I try to care about them.

    
    

    
  
Mike: what is your opinion on comment 13?

    
    

    
  
JD, can you please quit with the "me too" comments? Those of us CCed to this bug don't really care to be repeatedly spammed with comments saying the same thing over and over again.
https://bugzilla.mozilla.org/page.cgi?id=etiquette.html

    
    

    
  
As JD pointed out, on mac this sucks. If you could hold down the mouse button(mac style) to get the context meny, that would be ok. We mac users _need_ one of these two feature, but now we have none. It's such an annoyance to clear the download history on mac, compared to Fx2. Please add this button, at least in the mac theme.

    
    

    
  
I would again like to point out that this sucks on mac laptops. Even with osx configured to right-click with the two-finger shortcut, it is still too much effort. I know the functionality existed in Firefox 2, why the regression? Most modern browsers have this implemented, and I think it's a feature (although small) that will be missed by many if left out. 
No longer blocks: 397655

    
    

    
  
(hopefully I'm not stepping into the mud here)

Put me in the camp of adding a clear downloads button. This has been bugging me for a while now. My assumption was it would be fixed. Context menus should be specific to the item you click on. Right clicking a single download to clear the entire download list isn't intuitive.

    
    

    
  
(In reply to comment #29)
> I know the functionality existed in Firefox 2, why the regression?

I don't get it either.

        Attachment #300038 -
        Flags: review?

    
    

    
  
A clear list option seems to be the only way to quickly clear all items.

    
    

    
  
(In reply to comment #33)
> A clear list option seems to be the only way to quickly clear all items.
> 

"Select All" (Ctrl+A) plus "Delete" (Del) would be an alternative; but restoring the "Clear All" button would be a GoodThing™ too. (Why, but why, was it removed? No one could reasonably say it was "neither useful nor discoverable" this time!)

    
    

    
  
Moz folk(s) designed it so...

    
    

    
  
I've uploaded an addon here https://addons.mozilla.org/it/firefox/addon/6945 that add this feature.

    
    

    
  
We won't be doing this for Firefox 3.  We may revisit it in the future, and that decision will be based partially on the popularity of the add-on mentioned in comment 36.

As it stands, this bug is WONTFIX.
URL: https://addons.mozilla.org/en-US/fire...
Status: ASSIGNED → RESOLVED
Closed: 16 years ago
Resolution: --- → WONTFIX

    
    

    
  
shame on you, mozilla...

usability goes to /dev/null...

    
    

    
  
Well...Looks like in my mind that WebKit (and WebKit-based browsers/frontends) is getting better and Mozilla/Firefox/Gecko is going further and further down the tubes...Well...At least nowadays there's a good replacement.

Thank you Mozilla! You have pulled the same **** as Vista did with me and that made me go to linux...

    
    

    
  
Hey, don't spam this bug now... It is already "RESOLVED WONTFIX" even though it has a lot of votes. The obvious thing here is that usability doesn't concern Mozilla anymore. They're making Fx too unusable, and removing the discoverability of even this! By Fx4 there will be only a back button and you'll have to right click for everything. Thank you for your time, Firefox. It was fun.

    
    

    
  
(In reply to comment #39)
> Well...Looks like in my mind that WebKit (and WebKit-based browsers/frontends)
> is getting better and Mozilla/Firefox/Gecko is going further and further down
> the tubes...Well...At least nowadays there's a good replacement.
> 
> Thank you Mozilla! You have pulled the same shit as Vista did with me and that
> made me go to linux...
> 

This is a bug report system, not a place to shout opinions with with colourful words. I'd go in to the Pros and Cons of Fx2 to Fx3 vs. XP to Vista but it's really not worth it.

Find a more appropriate place to express such opinions. You can usually find me once a week in the Firefox IRC channel giving a good constructive complaint on the download manager for about an hour or so. I'm just going to pick up a download manager extension replacement when some good ones are made for Fx3, I suggest you do the same if you feel so strongly.

    
    

    
  
(In reply to comment #37)
> We won't be doing this for Firefox 3.  We may revisit it in the future, and
> that decision will be based partially on the popularity of the add-on mentioned
> in comment 36.
> 
> As it stands, this bug is WONTFIX.
> 

Translation: this feature is so popular that we won't add it.

People have given multiple, excellent reasons for bringing the clear button back. Saying "go find an addon" is a terrible and disheartening answer. You've greatly reduced the usability for novice users and they are precisely the group least likely to stumble upon an addon to fix an inexplicable omission on the dev team's part.

> Find a more appropriate place to express such opinions. You can usually find > me
> once a week in the Firefox IRC channel giving a good constructive complaint on
> the download manager for about an hour or so. I'm just going to pick up a
> download manager extension replacement when some good ones are made for Fx3, I
> suggest you do the same if you feel so strongly.

THIS IS THE APPROPRIATE PLACE TO GIVE CONSTRUCTIVE COMPLAINTS ON THE DOWNLOAD MANAGER.

    
    

    
  
I'm a Mozilla bigshot and I'm dismayed by this -- do I go off in a huff to some other browser? No, but I'm not sure I want to try that add-on.

sdwilsh, where was this spec'ed? I'd like to read the rationale. Or maybe you can cite a comment here explaining why the button was removed.

I'm not a huge downloader, but my download dialog is overlong now, and the scrollbar thumb shrinking is a noticeable distraction and probably a perf issue in some way. The list will grow without bound for most users. How is this a good idea, please?

/be


    
    

    
  
I am still interested to know what the opinion is about comment 13 from anybody
that think that there should be no "clear list" button.

And to extend that question, what is a more common case for a regular person,
to clear a huge download list or to search for something in that list?


    
    

    
  
BTW, one of my jobs is resolving disputes that a module owner does not handle to the satisfaction of enough people that there's a fight. So I'm already involved, and I do not want to be the decider. You (all of you) probably don't want that either. For the moment, please refrain from spamming this bug with vitriol -- I'm on the case.

At the very least, a rationale for the change and a convincing story for how almost all users won't have an unusably long list of downloads both need to be given here.

/be

    
    

    
  
> I've uploaded an addon here https://addons.mozilla.org/it/firefox/addon/6945
> that add this feature.

You know what I would change about this Mrtb, I'd move the search field to the
upper right of the window, which has become a standard UI convention in most
apps, including Fx. Then I'd slide the clear button over to the left, avoiding
the "click to close" problem. Just my 2 cents.

    
    

    
  
(In reply to comment #43)
> sdwilsh, where was this spec'ed? I'd like to read the rationale. Or maybe you
> can cite a comment here explaining why the button was removed.
This was based on the decision of the UX team.  I've asked them to handle this issue now since I *really* should be gone working on my school work for the next week.  I've only been around because we needed to upgrade sqlite...

    
    

    
  
In reply to comment #43

Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9pre) Gecko/2008041601 SeaMonkey/2.0a1pre

I don't know about Minefield, but in Suiterunner Ctrl-A (Select All) followed by Del will clear the Download Manager if it is the active window.

So, if you want to go off to some other browser than Fx3, why not try Sm2? They share a lot of code, but it isn't the same people who make the final decisions.

    
    

    
  
Would reopen if it would just me but Brendan Eich did not so why should I ? I think this should be REOPENED until a more than satisfactory explanation is given.

I consider myself as an advanced user and I used that button a lot. I find it very annoying to have to go in the context menu for a frequent task like that.

But my main concern is user with no or little technical knowledge. Putting this in the context menu means for them that there is NO WAY TO CLEAR THE LIST. My girlfriend that is testing beta 5 (without knowing) asked me where was the clear list button gone... Imagine her reaction when I starting speaking about the context menu. I (We) can't be there for every user that is looking...

This button should come back!

    
    

    
  
> THIS IS THE APPROPRIATE PLACE TO GIVE CONSTRUCTIVE COMPLAINTS ON THE DOWNLOAD
> MANAGER.
> 

1) No, this is the appropriate place to give constructive complains on the removal of the Clear List button to the download manager

2) Constructive complaints aren't full of attacks against Mozilla, swear words or written entirely in capitals.

    
    

    
  
#44 has a good point. I've never used and probably never will used the search function. I actually asked my friends just now if they use it. Turned of none of them had ever used it. Seems pretty useless to me. Why this and not "Clear list"?

    
    

    
  
FWIW, (In reply to comment #44)
> I am still interested to know what the opinion is about comment 13 from anybody
> that think that there should be no "clear list" button.

There is no disadvantage to having a long list; in fact, that's pretty important information to have, and speaks to our desire to help users revisit places they've been to before, and find things that they've already obviously expressed interest in. This is a major theme of Firefox 3: leveraging information in the user's client to their advantage.

> And to extend that question, what is a more common case for a regular person,
> to clear a huge download list or to search for something in that list?

Search has been seen to always be a predominant use case.

(In reply to comment #43)
> sdwilsh, where was this spec'ed? I'd like to read the rationale. Or maybe you
> can cite a comment here explaining why the button was removed.

Repeating from comment 20, the function isn't a primary use case for that window [compared to search] and the ability to clear the list exists on the context menu [and by multiple selecting and hitting "del"]. We should fix the fact that Ctrl/Cmd+A doesn't select all, but that's a separate bug.

What wasn't mentioned in that comment was that users should not be encouraged to remove information that is useful (see above). We're not removing the ability to do so, we're just not privileging it as much as we're privileging search. Putting the button on the dialog almost implies that it is something that the user should do often, and implies that it is the user's responsibility to keep the list clear (and indeed, previously had they not done so, they would have suffered for it in terms of performance when opening that list!). 

With the new backend design, sdwilsh assures that there is no performance impact to the list being long, especially as we chunk the display results. To control overall length, we might want to consider bug 251337 to implement the same sort of expiry/aging as exists in history.

Removing UI is always contentious, and we've actually taken pains to replace it with *two* new alternative ways to achieve the same effect: unlike previous versions, you can now use the Clear List item on the shortcut menu, or select multiple entries and press del. Additionally, you can prune your list more intelligently: want to get rid of all the PDFs? Search, select, clear.

I'm glad to see add-ons remain for people who wish to keep their list shiny and clean. I would also commend those users to the Clear Private Data entry for download history if they wish to keep that automated.

    
    

    
  
(In reply to comment #52)
> with *two* new alternative ways to achieve the same effect: unlike previous
> versions, you can now use the Clear List item on the shortcut menu, or select
> multiple entries and press del.

How about mac users? We don't have a del button and we don't have right-click. Yes ctrl-click, I know... But I like to do simple thing without using two hands.

If you don't want it to get to much focus just make it smaller like in Safari. Perfect!





    
    

    
  
That's a nice thought Beltzner, but

a) It means your trying to force user behavior

b) It takes forever to load a long download list! (I'm talking 500+ downloads). Even on a fast computer, 50 downloads take about 15 seconds to load.

    
    

    
  
(In reply to comment #52)
> with *two* new alternative ways to achieve the same effect: unlike previous
> versions, you can now use the Clear List item on the shortcut menu, or select
> multiple entries and press del.

How about mac users? We don't have a del button and we don't have right-click. Yes ctrl-click, I know... But I like to do simple thing without using two hands.

If you don't want it to get to much focus just make it smaller like in Safari. Perfect!





    
    

    
  
(In reply to comment #54)
> That's a nice thought Beltzner, but
> b) It takes forever to load a long download list! (I'm talking 500+ downloads).
> Even on a fast computer, 50 downloads take about 15 seconds to load.
> 

I can verify this as well on multiple systems (and just for the record, systems ranging from a 2.4GhZ P4 to a quad-core 3.2GhZ Xeon, so basically every range of the spectrum). There is DEFINITELY a significant pref impact with 25-50 entries in the download manager. 

    
    

    
  
Cato, Delete works just fine as well.

Damian, good UI design often means emphasizing some tasks over others.  Look at which items get primary placement in toolbars, etc.  The list might take a long time to load, that's because we're building it incrementally.  Your browser and the window should remain responsive throughout.
Status: RESOLVED → VERIFIED

    
    

    
  
JD, that's because we're building the list in fixed chunks, on a timer, so the same number of entries should take the same amount of time to display on many different systems.

    
    

    
  
(In reply to comment #57)
> Cato, Delete works just fine as well.

I don't have that button. Please read the next time. I think there might be some keyboard combination for it, though. But two different keyboard combinations after each other just for clearing the list? Pfft... Horrible usability!



    
    

    
  
(In reply to comment #57)
> Cato, Delete works just fine as well.
> 
> Damian, good UI design often means emphasizing some tasks over others.  Look at
> which items get primary placement in toolbars, etc.  The list might take a long
> time to load, that's because we're building it incrementally.  Your browser and
> the window should remain responsive throughout.

I figured that out, but it loads slower than I can read and is very annoying when I want to skip right to the end.

But that's not important, I like keeping my download box clear, but it doesn't have the power settings to put individual file types or select categories to particular folders, so my downloads never stay in the default directory.

The principle of the matter is:

* Clear List is not a context sensitive function

* Users clearly want it back, bugs do not normally get this many votes. This is what Beta is for, to find what users what. 

    
    

    
  
(In reply to comment #59)
> (In reply to comment #57)
> > Cato, Delete works just fine as well.
> 
> I don't have that button. Please read the next time. I think there might be
> some keyboard combination for it, though. But two different keyboard
> combinations after each other just for clearing the list? Pfft... Horrible
> usability!

Backspace works; have you tried it?

    
    

    
  
(In reply to comment #61)
> (In reply to comment #59)
> > (In reply to comment #57)
> > > Cato, Delete works just fine as well.
> > 
> > I don't have that button. Please read the next time. I think there might be
> > some keyboard combination for it, though. But two different keyboard
> > combinations after each other just for clearing the list? Pfft... Horrible
> > usability!
> 
> Backspace works; have you tried it?
> 

No, I didn't know that worked. Again proving how undiscoverable the function is. I don't think my grandma would think of that.


    
    

    
  
In reply to comment #52 by M.Beltzner

There is, or was, a long-outstanding bug which made it so that long download histories made Fx unbearably slow. I don't know if it was fixed, or if the Fx2/Fx3 transition cured it, but as long as it isn't (or wasn't) fixed, clearing the download history was a matter of hygiena. Even if it's now been fixed, you'll have a hard time re-educating all the users who got that reflex so well trained that they clear the D/L list with hardly a thought. If they don't find the button, they won't think they should keep the list, they'll look for some other means (context menu, Edit menu, whatever) to accomplish the same result, and won't rest until they've either found it, or found a different browser which has it.

Oh, and BTW, what is "important history info" to one user may be "private data not to be left in the Internet café" to another.

In reply to comment #61 by S.Donner
Delete isn't a button, it's a key (under Insert and left of End).

    
    

    
  
(In reply to comment #63)
 
> In reply to comment #61 by S.Donner
> Delete isn't a button, it's a key (under Insert and left of End).

Not sure why or where you thought that I said it was a button.


    
    

    
  
(In reply to comment #64)
> (In reply to comment #63)
> 
> > In reply to comment #61 by S.Donner
> > Delete isn't a button, it's a key (under Insert and left of End).
> 
> Not sure why or where you thought that I said it was a button.
> 

Does it matter? It's not there on macbooks no matter what it's called.


    
    

    
  
In reply to comment #64
My mistake, Cato said it.

In reply to comment #65
A button is something you click with the mouse; a key is something you press with a finger. So yes, if you want to be understood, it does matter which word you use.

    
    

    
  
I also agree that the Clear List button should remain, the same as it is in
Fx2.

First, you have a lot of Fx2 users who will consider the disappearance of the
button as an upgrade error; this may even cause a reinstall, trying to fix a
non-existent UI bug.

Second, the download list represents objects that are already dealt with, not
something important. Even most unexperienced users will move the downloaded
content to the appropriate location soon after downloading it.

Third, unlike maybe many others, I DO use the built-in download list a lot, and
I DO use the Clear List button often, and I NEVER needed to search this list,
although I use fx about 8-10 hours a day.

Usability is not about features being just available, it is about features
being available in the way they are the easiest to use. You can rule the whole
Fx by editing about:config and manually tweaking the profile, why the heck we
even need buttons and menus at all??


    
    

    
  
(In reply to comment #67)
> I also agree that the Clear List button should remain, the same as it is in
> Fx2.
> 
> First, you have a lot of Fx2 users who will consider the disappearance of the
> button as an upgrade error; this may even cause a reinstall, trying to fix a
> non-existent UI bug.

In my case, this is exactly what happened. I first ran Fx3 with a Fx2 profile and when I saw the big white box with no buttons that is the Fx3 download manager I thought something was wrong. After creating a new Fx3 profile I was rather perplexed when the download manager looked no different, which in turn led me here to bugzilla.

I, like #60, like my download manager clear and his reasons there and in comment #54 for bring the clear button back are sound.  

    
    

    
  
There's plenty of "hatin" going on here, so here's a proposal. How about an option, in the prefs somewhere, that I can enable, that will clear the download history when the download manager window is closed?

1) It's not interfering with the "Primary functions"
2) It's not easily confused for something else in that window
3) Keeps the UI clean
4) Default action is still to keep everything in the list (which is a stupid idea to me anyway, but that's another thread)
5) It partly gives back some of the control to the user that most here are looking for.

I would prefer a Clear List button (even a small one), but I would probably be ok with this option.

    
    

    
  
I think 'Clear List' button should really come back. I didn't even know how to clear the download list until I've read 30 or so comments from this bug this morning and I've been using Minefield in the last 2 years!

The bottom line is, many average users out there would not have a clue how to do so. For them, the disappearance of the 'clear list' button can either means an error on Firefox 3 (as mentioned)or a compelling reason not to upgrade to Firefox 3 and stick with Firefox 2 instead. 

This shouldn't be fixed by a add-on or prefs modification, unless only a small number of people are affected. But judging by the number of votes and comments, I'm inclined to think the otherwise. 

Not to mention this is not just a 'nice' feature to have, but for many, an essential one. I found it quite annoying when the download manager is more than 1 page long after 4-5 hours use of Minefield and had to clear it one-by-one. 

Please, Mozilla, bring back the button.

    
    

    
  
(In reply to comment #60)
> I figured that out, but it loads slower than I can read and is very annoying
> when I want to skip right to the end.
> 
> But that's not important, I like keeping my download box clear
You want to see the last item as well as see nothing at all?

The "slow" list building doesn't affect performance and builds somewhat independent of your computer speed. If you just want to look at your most recently downloads, the list will show you that right away. That's what it was optimized to show.

It also happens to show the rest of your downloads so that you can search it if you want.

As pointed out, you can delete thing with the delete key or the backspace key depending on your OS. You can even select multiple downloads and hit delete. You can do a search "april pdf" and use the context menu's clear list to only clear those downloads listed.

It sounds like a lot of people here just want the list empty.

There's a option under Privacy.
[] Remember what I've downloaded

    
    

    
  
> a compelling reason not to upgrade to
> Firefox 3 and stick with Firefox 2 instead. 
> 

*chuckles*  I want the button back too, but don't you think that "compelling reason to not upgrade" is just a wee bit extreme for one button on one dialog?

(The rest of this message is addressed to the audience in general)

FWIW, nobody complained about the loss of the clear cookie button or the clear history button (they, along with clear downloads, have all been lumped into the omnibus clear private data thing).  So if someone really is paranoid about their privacy, they will surely have to clear cookies, passwords, history, etc. as well, and since they're already going to use the clear-private-data thing, why not just tick an extra box there while they're at it?  Or if you're really paranoid, you could turn off remember downloads all together.

The problem of too many entries in the download manager killing Firefox performance should be fixed in Firefox 3, so beyond the concerns for privacy and the desire to remove the "old stuff", there shouldn't be any need to clear it.  And if you are concerned about privacy or if you like to remove old things, then why aren't you also clearing your history?  And if you're clearing your history, then why not clear your downloads at the same time in the same interface?

Now, I do want the download button back.  But for different reasons (namely, because I'm a purist who thinks that context menus should operate on an item, not on the whole list and because I'm just so used to it), and I think that *some* (note my emphasis; I'm not trying to make blanket statements) of the arguments here (e.g., the ones about privacy) are not very valid.

In any case, please do stop spamming this bug with "me too" messages.  Vote for the bug if you want it back or.  Or comment if you have a suggestion for how to deal with the issues that contributed to this bug's removal (namely, that it occupies a location usually occupied by OK, and the desire to nudge people to realize the joys of being able to look back at one's past), and to that end, I think that Brendan came up with a nice compromise (reduce the button size and swap its location with the search box) that has unfortunately been buried by all these "me too" messages.  :-P

    
    

    
  
> You want to see the last item as well as see nothing at all?
> 
> The "slow" list building doesn't affect performance and builds somewhat
> independent of your computer speed. If you just want to look at your most
> recently downloads, the list will show you that right away. That's what it was
> optimized to show.
> 
> It also happens to show the rest of your downloads so that you can search it if
> you want.
> 
> As pointed out, you can delete thing with the delete key or the backspace key
> depending on your OS. You can even select multiple downloads and hit delete.
> You can do a search "april pdf" and use the context menu's clear list to only
> clear those downloads listed.
> 
> It sounds like a lot of people here just want the list empty.
> 
> There's a option under Privacy.
> [] Remember what I've downloaded
> 

Please don't patronize users like they don't know what they want, they want a clear way to remove the list when they like it.

My usage of the download manager and this is similar to most peoples I've seen is to download a lot of stuff in a period of time (a day, 2 days, a week) and then clear the list. The list gets cleared when I move the downloads to a more context sensitive folder, which the light style Firefox download manager doesn't have the power to do (something which I'm all fore, light is good).

So it's more than normal to:

a) Have lots of downloads on the download manager and want to quickly get to the last one

and 

b) Have a clear and quick way to remove all the downloads off the list.

And this is a single user, it wouldn't surprise me if a large % users want just (a) and a large % of users want just (b).

    
    

    
  
(In reply to comment #72)
> there shouldn't be any need to clear
> it.  And if you are concerned about privacy or if you like to remove old
> things, then why aren't you also clearing your history?

There's shouldn't be a list that remembers for more than one browsing session to begin with, IMO. But that's just me. Why aren't I clearing my history? My business is my own and I'll clear what I want, when I want. Maybe I want an easy way to clear the download list. I have the option to clear things on FF close, why not the download manager close?

I just need it in the list long enough so that I can see when it's done. Then I want it clear, but not before I see it. And when I want it clear I want it done easily. Not through 2 clicks, opps, that was an active download, have to do reselect a finished one, now I can clear it. It's bull.

> In any case, please do stop spamming this bug with "me too" messages.

I hope you know how to remove yourself from the list if you don't want to get any more mailings.

    
    

    
  
(In reply to comment #74)
> There's shouldn't be a list that remembers for more than one browsing session
> to begin with
browser.download.manager.retention -> 1: When the browser exits

> reselect a finished one, now I can clear it. It's bull.
Fixed with bug 426983.

    
    

    
  
(In reply to comment #74)
> > In any case, please do stop spamming this bug with "me too" messages.
> 
> I hope you know how to remove yourself from the list if you don't want to get
> any more mailings.

That's not the correct attitude to have. The Bugzilla Etiquette (https://bugzilla.mozilla.org/page.cgi?id=etiquette.html) clearly says "No pointless comments," and "me too" messages _are_ examples of pointless comments. If you don't have anything constructive to add to this bug, please either keep it to yourself or take your discussion to the newsgroups. Thanks!

    
    

    
  
For those interested:
 - bug 251337 is about automatically aging/expiring entries
 - bug 429614 is about hooking up select all to the download manager

    
    

    
  
Expiring entries might be good. Even better if entries where I have moved the file would be removed automatically. Is there a bug on that?

The bugs cited in comment 77 are not going to be fixed for Firefox 3, AFAICT, so they don't mitigate the loss of Clear.

The problem with the theory that search is the dominant use-case, from all the testimony here, is that it does not reflect many users' habits. It's a model based on useful filenames, which are rare in my experience (numbered papers and cryptic 8.3 names are too common). If filenames are not usefully searchable, then it loses.

Worse, many users testifying here move downloaded files elsewhere, using filesystem UI. Filesystem UI is much broader in bandwidth and utility than the download dialog; this is obviously true and probably inevitably so. If one is not going to let downloads pile up (on the Desktop by default), then again: search is not useful in the download dialog, except for visually scanning the last N (small N, 7-10?) items, to avoid re-downloading and to judge when filesystem-UI driven housekeeping is in order.

Is there any data for the theory that search is the dominant use-case?

The testimony here has to count as data of more bits than I can see for the model on which the UI is based.

In the absence of evidence, being conservative and keeping the Clear button which some users rely on in Firefox 2 and earlier is the right course.

If the bugs in comment 77 were fixed, and (I think this should be on file if it is not yet) moved files were automatically purged from the list, then removing Clear might be tenable. But since those bugs have not been fixed, removing Clear just breaks many users. It's out of order. Wherefore this bug, which should not be WONTFIXed without more evidence or else other bugs being fixed *first*.

Re-opening.

/be
Status: VERIFIED → REOPENED
Resolution: WONTFIX → ---

    
    

    
  
#72 Kai Liu:
Combined with other major changes to the defauly way Firefox works (such as text zooming and zooming by the site rather than by the tab) the removal of this one button can indeed be the final straw that becomes a "compelling
reason to not upgrade." The fact that we're having so much trouble finding out the logic that prompted the change doesn't help one bit.

I didn't mind as much when the clear cookie or history button got lumped into the omnibus Clear Pivate Data settings, but this is a different case. This isn't something that was found in the preferences window, it was right there in the Download Manager. Now we have to jump through hoops or try an extension to try to regain a behavior that's been in Firefox for as long as I can remember. (I've been a Firefox user since before 1.5.)

Yes, we're angry. Yes, we're **** off, and shouting out a window that we're not taking it anymore isn't going to help at all. Which is why we've come to Bugzilla to try to get our issues addressed.

    
    

    
  
Kai Liu: I don't know how you think your helping your case by swearing, but there we go. I agree with you completely, but bugzilla is not the place to be opinionated and emotional, it's the place to provide strong objective rationale. 

To change zoom behavior to tab specific, go to: about:config (type it in to your address bar and hit enter). Then set browser.zoom.siteSpecific to False. I

'm told site specific zooming was a highly requested feature. If you have problems with default behavior of Firefox, that's what settings and extensions are for.

    
    

    
  
(In reply to comment #78)
> The problem with the theory that search is the dominant use-case, from all the
> testimony here, is that it does not reflect many users' habits. It's a model
> based on useful filenames, which are rare in my experience (numbered papers and
> cryptic 8.3 names are too common). If filenames are not usefully searchable,
> then it loses.

I don't think I agree that useful filenames aren't common enough to make this feature useful, but I should point out that you can search on more than just the filename - the date and URL are also searchable. This can be useful for finding "all downloads from mozilla.com" and "all downloads from April 1st", for example.

    
    

    
  
(In reply to comment #81)
> (In reply to comment #78)
> > The problem with the theory that search is the dominant use-case, from all the
> > testimony here, is that it does not reflect many users' habits. It's a model
> > based on useful filenames, which are rare in my experience (numbered papers and
> > cryptic 8.3 names are too common). If filenames are not usefully searchable,
> > then it loses.
> 
> I don't think I agree that useful filenames aren't common enough to make this
> feature useful,

YMMV.

> but I should point out that you can search on more than just
> the filename - the date and URL are also searchable.

Again YMMV (downloading for me is bursty, I do a lot in an unknown but short amount of time, then little for a while; I download from one domain name with ugly path parts -- ACM portal -- so that's not helpful).

Also how discoverable is search by date?

> This can be useful for
> finding "all downloads from mozilla.com" and "all downloads from April 1st",
> for example.

Those are actually parsed? Probably not, but could you give the exact query text?

Even if search is the new model that wins over time, it has discoverability issues, and users have habits based on filesystem and OS search and drag-drop. The idea that the download dialog can overcome these habits is optimistic at best. Removing Clear in the mean while is, again, out of order (never mind the other unfixed bugs mentioned in comment 77).

/be 



    
    

    
  
> I don't think I agree that useful filenames aren't common enough to make this
> feature useful, but I should point out that you can search on more than just
> the filename - the date and URL are also searchable. This can be useful for
> finding "all downloads from mozilla.com" and "all downloads from April 1st",
> for example.
> 

I think having a powerful search box is great and could of been brilliant for power users and the odd standard user who got used to such lateral searching (which the awesome bar may teach users to do). I don't think being implemented in such a light download manager makes it useful. But this all assumes that the user keeps the download in the default download directory, it's not my experience that users do do that. 

Maybe there's evidence to the contrary, I don't see why Mozilla doesn't do more studies in to user behavior like this.


> > finding "all downloads from mozilla.com" and "all downloads from April 1st",
> > for example.
> 
> Those are actually parsed? Probably not, but could you give the exact query
> text?
> 
> /be 
> 

I actually remember this bug and know about this feature, only because I'd seen the bug be implemented, to search for all downloads from mozilla.com simply type:

mozilla.com

to search for everything from April 1st, type:

April 1

There's 2 issues with that search of course:

1) All results from April 10, 11, 12, etc.. show

2) It only works if April 1st is more than a week old

    
    

    
  
Searching would have been more detailed had the Download History, and Advanced Search not been removed from the Library.  As it stands now, for my use, it has none.

I don't know if the 'Search' in the DM was added to aid in the Library hook-up or not, just throwing out more food for thought.

Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9pre) Gecko/2008041804 Minefield/3.0pre Firefox/3.0 ID:2008041804

    
    

    
  
The download manager isn't a replacement for the operating system's file browser.

It's there to manage active downloads. (Personally, I just look at the statusbar and turn off showing the download manager.)

But it's also your download history list to find something that you've downloaded some time ago. For most users, I would guess that the majority of the files listed aren't actually at the original download disk location anymore, but the download manager is more than just opening files that you've downloaded.

You can search for a cool file you spent some time finding on the internet and revisit the page you downloaded it from to see if there's anything else neat.

Or just find a file and redownload it if you don't want to search your computer or know you deleted it.

You can even share download links with your friends by selecting multiple downloads and copying the download link.

And to find any of the files in the first place, you can search by file name, file extension, finish date, server's domain, or file size if you really wanted.

"blog htm dec moz kb" -> "the Burning Edge weblog.htm  December 5; 55.6 KB -- mozilla.org"

Or something probably more useful "starcraft" -> "Terran Demo English.avi... starcraft2.com" -> "Go to Download Page". Hey neat, there's a Zerg trailer now.

    
    

    
  
Mardak: No one here is arguing that the search isn't powerful and that the download should the replace the OS file browser. That doesn't address any of the concerns raised in this bug.

Although should I make a new bug on there being no consistent way to find downloads from April 1st using this search box? Or isn't that feature too cared about? (i.e April 1 comes up, not April 1st, so searching April 1, brings me results from all over the place not just April 1st).

    
    

    
  
To add to Damian's comment 86, there's a fallacy here:

  (!search-useful-for-some) -> want-clear

is true AFAICT, but it does not imply

  search-useless

Likewise, and stronger:

  search-useful-for-everyone

does not imply

  drop-clear

Sorry if this is obvious. It seems like it's not. Search plus expiration plus file-rename tracking of some kind could lead to losing clear, maybe. We need much more evidence before cutting Clear, and well-ordered feature work too.

/be

    
    

    
  
Clear hasn't been cut; you can Right Click > Clear List still.

    
    

    
  
The concern is that if there was auto-expire of say.. 6 months, I wouldn't have found the Terran Demo download from September 14.

Or if there was an easily accessible Clear List button in the primary UI, I probably wouldn't be able to even find anything from a week ago. I know that when I used Firefox 2, I would be OCD and clear the list every time. Why? Just because it was there and easy to click. It's even sitting around like an OK button to close the window that people are so used to clicking through. I definitely ran into situations where I wish I didn't clear the list because I wanted to find a download site.

There isn't really a negative perf impact for keeping the list around. And keeping it around allows users to find something if they want. But you can't find anything if you don't have a list to begin with. Similarly, if we had a big "clear history" button that appears after every time you load a page, I'm sure people would be negatively impacted because they wouldn't be able to make use of the Awesomeness.

The option to clear the list is available in many forms, but UX has decided that it isn't something beneficial in the primary user interface. Or alternatively, having it in the main download window would negatively impact other features.

    
    

    
  
(In reply to comment #82)
> > but I should point out that you can search on more than just
> > the filename - the date and URL are also searchable.
> 
> Again YMMV

I meant that they are "searchable" because you can search for substrings within them, not that searching them is necessarily always useful.

> > This can be useful for
> > finding "all downloads from mozilla.com" and "all downloads from April 1st",
> > for example.
> 
> Those are actually parsed? Probably not, but could you give the exact query
> text?

No, they aren't - "mozilla.com" and "april 1" would be the actual search terms to use to get those results.

My initial reason for commenting in this bug was just an attempt to clear up what I perceived to be a misunderstanding of the feature that might impact reasoning about how to resolve this bug. To be clear, I was initially in favor of restoring the clear button. Madhava and I discussed it briefly, and he brought up the point that having a button there could make users feel that they are responsible for clearing the history, or that imply that there's a need to do it regularly. It also makes it easier to clear the history accidentally, which causes "dataloss" if you find that history (and the searching) useful.

It seems that a lot of users (myself included, even) feel a need to clear the list, and it's not obvious to me why they feel that need. In the past we've had performance issues caused by large histories, but we've mostly solved that problem as far as I can tell. It could be that some people are just resistant to change their habits, and don't like that we're now forcing them to re-evaluate the reasons behind that need by removing the button. Maybe this alone is reason enough to just restore it - I don't feel strongly either way. 

Perhaps restoring it is the lowest-cost option we have - I don't think there's *that* much resistance to the reversion itself from anyone involved. I think the resistance is coming mostly from not wanting to succumb to the will of a vocal minority of bug-commenters - a set of people who seem more likely to be resistant to change, and are not always representative of the type of users that make up the majority of our target market. I think the UX/UE team and the Firefox module owners have generally done a good job of making the right choices in the face of a lot criticism - it's hard to change anything without pissing *someone* off - and while I recognize the importance of making defensible and justifiable decisions, and being able to back them up, I worry that we're nearing a state of not being able to make *any* changes without a lot of conflict-resolution "process" getting in the way. But I digress, and I have a plane to catch - this last paragraph probably belongs in a newsgroup post, and not this bug.

    
    

    
  
(In reply to comment #88)
> Clear hasn't been cut; you can Right Click > Clear List still.

Let's not cycle over the argument that Clear is undiscoverable and most users' lists will grow without bound. Arguing otherwise is making an extraordinary claim and it needs lots of evidence.

(In reply to comment #89)
> The concern is that if there was auto-expire of say.. 6 months, I wouldn't have
> found the Terran Demo download from September 14.

Ok, let's not solve auto-expire here. It was one of the bugs in comment 77 that was used to justify removing Clear, except that it's unfixed and justification has to flow from cause to effect, forward in time :-/.

> Or if there was an easily accessible Clear List button in the primary UI, I
> probably wouldn't be able to even find anything from a week ago. I know that
> when I used Firefox 2, I would be OCD and clear the list every time.

Stop trying to train users with undiscoverable UI. That only annoys some users, fails to train others who already do what you want.

> There isn't really a negative perf impact for keeping the list around.

The background growth of the list, with scrollbar thumb shrinking, may now avoid starving the UI -- well done if so. It can't be cost-free, however. And its main impact is to suggest an unusably long list, which is indeed what almost every users will end up with if we ship as-is.

> And
> keeping it around allows users to find something if they want. But you can't
> find anything if you don't have a list to begin with.

Sure, no one here has argued for zero-length list.

> Similarly, if we had a
> big "clear history" button that appears after every time you load a page, I'm
> sure people would be negatively impacted because they wouldn't be able to make
> use of the Awesomeness.

That's an invalid argument, because you are assuming your conclusion, and ignoring the negative effects on those who do Clear judiciously and use the filesystem UI to move downloads around and organize them searchably via the OS.

> The option to clear the list is available in many forms, but UX has decided
> that it isn't something beneficial in the primary user interface.

That's the issue here. Are you arguing from "UX" authority?

> Or
> alternatively, having it in the main download window would negatively impact
> other features.

Please don't argue from undemonstrated assumptions or personal authority.

/be



    
    

    
  
Just put the damn button on the download manager. So we can clear this stupid bug and I can stop receiving emails about it.

    
    

    
  
(In reply to comment #91)
> (In reply to comment #88)
> > Clear hasn't been cut; you can Right Click > Clear List still.
> 
> Let's not cycle over the argument that Clear is undiscoverable and most users'
> lists will grow without bound. Arguing otherwise is making an extraordinary
> claim and it needs lots of evidence.

What's wrong with an unbound download history?

    
    

    
  
(In reply to comment #90)
> No, they aren't - "mozilla.com" and "april 1" would be the actual search terms
> to use to get those results.

As noted by others, this is problematic sometimes -- followup bug?

> Madhava and I discussed it briefly, and he
> brought up the point that having a button there could make users feel that they
> are responsible for clearing the history, or that imply that there's a need to
> do it regularly.

There is a perceived need based on users' habits of renaming downloads and using filesystem UI, which means the download list items are deadwood and worse -- they come up in searches but can't be opened. That's a real problem and a reason to clear, or prune by removing individual items. Since some users do such housekeeping en-masse, clear is useful.

> It also makes it easier to clear the history accidentally,
> which causes "dataloss" if you find that history (and the searching) useful.

This is true, but downloading occurs after web searches and the like; one can always re-search. Sometimes you have to anyway, because you lose the local copy and the old URL dangles.

These are all hard cases. If we think dataloss is significant, we can add an annoying confirming step to the Clear interaction -- but let's not without more evidence.

> It seems that a lot of users (myself included, even) feel a need to clear the
> list, and it's not obvious to me why they feel that need. In the past we've had
> performance issues caused by large histories, but we've mostly solved that

"mostly"?

> problem as far as I can tell. It could be that some people are just resistant
> to change their habits, and don't like that we're now forcing them to
> re-evaluate the reasons behind that need by removing the button.

No, you are ignoring the users who use filesystem UI to clean their desktops and therefore *do not want dangling entries* in their download lists.

> Maybe this
> alone is reason enough to just restore it - I don't feel strongly either way. 

Habits can be broken at some cost if they are "bad habits", but in the case at hand the filesystem-housekeeping habits are not bad in any sense that I can see.

If you grant there's nothing wrong with clearing after cleanup, then the only argument is training the user to see that Search trumps cleanup. But that needs more evidence, and it anyway leads to a cluttered desktop -- or back to the wish to remove dangling list items.

> Perhaps restoring it is the lowest-cost option we have - I don't think there's
> *that* much resistance to the reversion itself from anyone involved.

Good to hear.

> I think
> the resistance is coming mostly from not wanting to succumb to the will of a
> vocal minority of bug-commenters

This is bogus. Sorry, it's a trap that I can understand front end folks falling into, given the bad manners of some complaining parties here (Chris Alvares, you can remove yourself from the cc: list or be quiet -- other behavior of the comment 92 kind is not helpful and it's not welcome). But it is completely irrelevant.

> ... - and while I recognize the importance of making
> defensible and justifiable decisions, and being able to back them up,

That is the problem here.

> I worry
> that we're nearing a state of not being able to make *any* changes without a
> lot of conflict-resolution "process" getting in the way.

Bogus, stop worrying, attend to valid evidence-based (sound) and logical (valid) arguing.

> But I digress, and I
> have a plane to catch - this last paragraph probably belongs in a newsgroup
> post, and not this bug.

Maybe, but if it shows where the misapprehensions lie that led to this bug being WONTFIXed without enough evidence, then it was helpful.

I'm only the authority for conflict resolution and I do not want to argue from my personal authority for any particular technical solution, although I can make a case not based on authority for _stare decisis_ (let the Clear button back in as prudent conservation of pre-existing UI). This may be the thing to do given the inadequate modeling and reasoning about Search uber alles.

/be

    
    

    
  
(In reply to comment #93)
> What's wrong with an unbound download history?

Are you serious, or was that rhetorical? We don't have a narrow, items-as-buttons UI for unbounded global history.

If the argument is that Search is enough, then the list is useless if overlong, or at any non-zero length if Search truly is "enough".

So the UI is at cross purposes. Since Search is not enough, you need something that displays all items downloaded, but a tree widget is not in the current UI. And you need to be able to clear (discoverably).

/be

    
    

    
  
Isn't it still clear that enough users have enough arguments for this button to be back? Are you still listening to the community? Is UX team infallible?

Instead of looking of how many people will go and install the extension that gets the button back, why not looking for an extension that removes this button? I doubt if one exists, and I doubt if anybody will create one in the foreseeable future.

I use Mozilla since Moz Suite 0.8, and switched to Firefox since 0.9, and I am in UI design and usability since 2002. My voice doesn't count for much, but still you are WRONG if you remove that button.

    
    

    
  
I think I came upon this bug about half-way through, but I think there's a reasonable compromise to be had here, so I'll propose it.

Restore the "Clear All" button to the UI for Fx3, and ship with it.

With the "expire old history" bug (or another), add a download history table to a sqlite database, and let it grow bounded only by that expiration time; don't clear it with the "Clear All" button, just clear the downloads displayed in the UI. (or flag the existing table with a flag that indicates a d/l shouldn't be displayed, if such a table already exists).

I think this compromise very much gives all users the best of both worlds and restores what I think is a comforting, familiar, useful piece of the Fx2 UI.

We can start training people on the d/l manager search features post-1.9.

    
    

    
  
(In reply to comment #94)
> As noted by others, this is problematic sometimes -- followup bug?
Absolutely.  Filed bug 429720.

> There is a perceived need based on users' habits of renaming downloads and
> using filesystem UI, which means the download list items are deadwood and worse
> -- they come up in searches but can't be opened. That's a real problem and a
> reason to clear, or prune by removing individual items. Since some users do
> such housekeeping en-masse, clear is useful.
There seem to be two sets of operating assumptions here dictating mental models.  There's the group that has the assumption that the download manager is only used to open files once downloaded, and the other group who feels that it's used for that and finding what you've downloaded in the past on the file system and/or the internet (Go to Download Page/Copy Download Link in the context menu).

The problem (as I see it), is that the first group doesn't feel that the assumptions the second group has made (that users can/will use the download manager to go back to where they downloaded something from) are correct.  Group two wants to de-emphasize the clear button because users have a habit of clearing the download history due to performance issues.  I'm making that claim based on an informal study of talking users of Firefox 2 around campus, and looking at blogs and help sites that recommend you do that if you think your download manager is performing slowly (as well as at least one comment in this bug).  It was decided to be OK to de-emphasize this UI because those performance issues have gone away (last I checked I had over 500 downloads and have no performance issues on my nearly two year old macbook).

> These are all hard cases. If we think dataloss is significant, we can add an
> annoying confirming step to the Clear interaction -- but let's not without more
> evidence.
What evidence do we have to add it back?  I'll note that this button has been missing from the UI for something like six months now, and until it was marked as WONTFIX, there weren't many dupes filed against it, nor was there much bug activity.  This made it through the last three betas with much of an uproar, which to me indicates that most users are OK with it.  The feature still exists, it's just not prominent anymore.

To counter the point that this bug now has a lot of activity and votes, so that is evidence to re-add the UI, I'm going to point to another bug.  Bug 18574 has 744 votes and is VERIFIED WONTFIX.  Yes, part of the reason for it being marked as such is technical reasons, which this bug is lacking.  I'm merely using it to demonstrate that activity in a bug should not indicate support one way or another for a feature (it can be used as a factor).  Bug 388195 is another bug where the opposite is happening - people don't want the bug to go through.

> No, you are ignoring the users who use filesystem UI to clean their desktops
> and therefore *do not want dangling entries* in their download lists.
This comment operates on the assumption that the download manager is only used for accessing the file locally.  Not only that, but modern OS's don't place the files on the desktop anymore, and we obey that.

> If you grant there's nothing wrong with clearing after cleanup, then the only
> argument is training the user to see that Search trumps cleanup. But that needs
> more evidence, and it anyway leads to a cluttered desktop -- or back to the
> wish to remove dangling list items.
Doesn't the awesomebar already demonstrate that search trumps cleanup?  I'll be the first to admit that the download manager search isn't as powerful, but we haven't spent nearly as much time on it.  You second point seems to assume that the download manager is only used to open local files again.

> > ... - and while I recognize the importance of making
> > defensible and justifiable decisions, and being able to back them up,
> 
> That is the problem here.
I felt that beltzner did an excellent job in comment 52 to provide an argument for the decision.  I haven't seen any comments that actually pick apart his argument, so it's unclear to me why you feel that that is the problem here.

> Maybe, but if it shows where the misapprehensions lie that led to this bug
> being WONTFIXed without enough evidence, then it was helpful.
This bug was WONTFIXed as a formality, since it was removed from the UI spec in bug 397655, which had some discussion on this issue.  I apologize for not explaining it well enough in the comment when I WONTFIXed the bug - I seem to have this problem of imagining people being able to read my mind.

    
    

    
  
*sigh*

    
  
Whiteboard: [see comment 52 for UX decision]

    
    

    
  
(In reply to comment #98)
[...]
> There seem to be two sets of operating assumptions here dictating mental
> models.  There's the group that has the assumption that the download manager is
> only used to open files once downloaded, and the other group who feels that
> it's used for that and finding what you've downloaded in the past on the file
> system and/or the internet (Go to Download Page/Copy Download Link in the
> context menu).
> 
> The problem (as I see it), is that the first group doesn't feel that the
> assumptions the second group has made (that users can/will use the download
> manager to go back to where they downloaded something from) are correct.  Group
> two wants to de-emphasize the clear button because users have a habit of
> clearing the download history due to performance issues.
[...]

I think I belong to group one (I prefer to have the download manager empty when a new downloading session starts, and so I clear it when it shows that all downloads for the current session are finished) but I'm conscious that it is only a personal choice and I'm not offended by having people around who never clear their D/L history because they use it for searching.

If only these people (your group two) wouldn't enforce their preferences on us! The rare times when I still recite the Lord's prayer, when it says "deliver us from evil" I translate it as "deliver us from the people who want to do, against our will, what _they_ call «our own good»".

    
    

    
  
Isn't there a reason why we have a Preferences dialog?  How about leave the button on by default, and the select few who don't like it can turn it off.

    
    

    
  
(In reply to comment #101)
> Isn't there a reason why we have a Preferences dialog?  How about leave the
> button on by default, and the select few who don't like it can turn it off.

And turn it off by default for new users (as opposed to upgrades from 1.5 and 2.0), because it might be removed in the next version.

    
    

    
  
(In reply to comment #98)
> > These are all hard cases. If we think dataloss is significant, we can add an
> > annoying confirming step to the Clear interaction -- but let's not without more
> > evidence.
>
> What evidence do we have to add it back?

Sorry, you changed the "it" at question. I'm talking about not removing the Clear All (or whatever it's called) button without evidence proving a positive: that Search, expiration, file rename tracking, etc. make it unused. You changed to prove a negative: that no one (or nearly no one) will object if Clear is gone in Fx3.

> > No, you are ignoring the users who use filesystem UI to clean their desktops
> > and therefore *do not want dangling entries* in their download lists.
>
> This comment operates on the assumption that the download manager is only used
> for accessing the file locally.

No, it makes no such "for all" or universal assumption. It's based on the *observation* that some people (complaining here, including me) do use the filesystem to organize and find downloads, so want the download dialog only for short-term memory -- and we clean up in bursts where Clear is useful.

> Not only that, but modern OS's don't place the
> files on the desktop anymore, and we obey that.

Where, then? I must have an old profile. The point is that anywhere is no good if the file is renamed to somewhere else, as some people do in order to use the OS to search and manage downloads in other than the short term.

> Doesn't the awesomebar already demonstrate that search trumps cleanup?

Evidence! This is all beside the point. Get testpilot to instrument Fx3 users and show that they discover how to Clear if needed, or don't clear, or (more to your point) do use the search often. Then we can talk about changes that effectively remove useful buttons (Clear is undiscoverable on the context menu).

>  I'll be
> the first to admit that the download manager search isn't as powerful, but we
> haven't spent nearly as much time on it.

Then don't remove Clear All yet.

> You second point seems to assume that
> the download manager is only used to open local files again.

No, you are again ignoring my "you are ignoring the users who use filesystem UI" words. I never said "all users" or made an unstated assumption. I'm talking about real users complaining here, including me.

/be

    
    

    
  
(In reply to comment #101)
> Isn't there a reason why we have a Preferences dialog?  How about leave the
> button on by default, and the select few who don't like it can turn it off.
> 

The problem with this is, if iterated enough, you'll have a product like the old Mozilla Suite, something that had everything, and an option for everything.  And we all know how popular that was...  And as much as I hate to admit it, comment 98 has a point: this bug's been quiet and there hasn't been a huge outcry about this, and suddenly, within just 24 hours of the WONTFIX, the comments trebled.  Do we really want a checkbox in the options dialog for one button in one dialog that?  A hidden pref is better, but not great.  And making the pref apply differently to new profiles will probably just cause confusion.

Ideally, Firefox should be using extensions as a way to prevent the "runaway features/preferences" problem of the Suite, and I think that this is a perfect candidate for that.  Unfortunately, that model doesn't really work for several reasons: extensions are not easily discoverable (though hopefully FF3 may change that, but that remains to be seen) and extensions have varying levels of quality--some may be outdated, some are buggy, some are inefficient, some leak memory or cause various other problems in Firefox, and I've been bitten by enough extensions that degraded performance or leaked memory that I tend to avoid them in general.  Making them more discoverable and also creating a new status/label at AMO for official Mozilla extensions (e.g., DOMi, Chatzilla, Download Manager Clear List) where there's a guarantee of a level of QA equal to that of Firefox may make the shove-feature-off-to-an-extension idea more workable.

In the meantime, I think we should just place a (diminished) button off to the side because...

1) Enough people are used to seeing the button that they may find it uncomfortable to see it missing.  People like the familiar.  And for me personally, it took a month or so of using nightlies before I finally got used to the button being gone.

2) Pedantic correctness.  :P  Context menu on an item should operate on that item.

3) While I like the idea of search and I think it's a good use model, I am not so sure about this idea of pushing people towards it.  It seems mildly patronizing and parental, and it can rub people the wrong way (c.f., all the comments in this bug).

4) Regardless of what great potential it may hold, search will not become a usage model overnight; that's just wishful thinking.  Everything needs time.  While there are great examples of how the search can be used, the biggest problem is getting people to think of using the search.  To that end, we are already doing all that we can by just having the search box there.  Granting that search box a monopoly won't make it significantly more discoverable.

I don't know how many people had similar experiences, but when I first found Wikipedia, I thought, "oh, this is neat", but I didn't use it very much because every time I had a "I wonder if..." thought fly through my mind, it simply didn't trigger a corresponding "let's look it up" response before the thought disappeared.  It was only with time--months of it--before I finally got to the point where I used WP on a regular basis.  The same is true for search, methinks.  You have to give people time to get used to it and for them to add it to their "mental toolbelt", and this is not a process that can be rushed (and certainly not by granting the search box a monopoly).  And you also need time for people to get out of the clearing habit.  If search really is as great as people make it out to be (and I think it very well may be), they will stop clearing on their own as they slowly recognize the power of the search.  But please, don't force it.  Maybe by the time Firefox 4 rolls around, we'd have a better idea of what people do and we could make a more informed decision, but for now, I think we should consider 3 to be the necessary transitional period.

So in a nutshell, I'm not against search (and I doubt anyone here is), but I think we need to go slowly: allow people a chance to transition from one model to the next, and also allow us the time to collect the evidence to determine if search really is the primary usage model and not just something that sounds nice in theory.

    
    

    
  
(In reply to comment #104)

> Ideally, Firefox should be using extensions as a way to prevent the "runaway
> features/preferences" problem of the Suite, and I think that this is a perfect
> candidate for that.

Personally, I think the search function should be an extension. To me it just seems like bloat, while clearing the list is a basic function. 


    
    

    
  
It was said that no one has successfully rebutted comment #52 as the end-all
reason to not put the Clear All button back in. Here is my attempt.

(In reply to comment #52)
> There is no disadvantage to having a long list; in fact, that's pretty
> important information to have, and speaks to our desire to help users revisit
> places they've been to before, and find things that they've already obviously
> expressed interest in. This is a major theme of Firefox 3: leveraging
> information in the user's client to their advantage.

I use my download list as an inbox. Once I've ran, viewed, whatever the item,
it gets cleared. Similarly I use my email inbox as, yes, an inbox. Once I've
replied, addressed, ignored an email, it gets moved to my archive or deleted. 

> Search has been seen to always be a predominant use case.

Great! I use my OS file search for that. Please do note that it correctly
handles moved files, deleted files and renamed files in a way that the Fx3 does
not (and likely won't ever). 

Similarly I use TB as my email client. I do use the whatever-the-quick-filter
bar is called to search my inbox (which I use as an inbox only, remember). If I
need to find something in the deep, dark past, I use the full TB search, which,
again, works regardless of where I happened to have moved email (unlike Fx3).

> Repeating from comment 20, the function isn't a primary use case for that
> window [compared to search] and the ability to clear the list exists on the
> context menu [and by multiple selecting and hitting "del"]. We should fix the
> fact that Ctrl/Cmd+A doesn't select all, but that's a separate bug.

It has been mentioned MANY times and NEVER (AFAIK) rebutted, that the context
menu Clear is (1) undiscoverable, (2) breaks the contxt-sensitive menu model
(it's called a context menu for a reason, ya know?) and (3) problematic for Mac
users. 

Also, how can search be the primary (and apparently only) use case for the
download manager if the feature never existed through Fx1 and Fx2? 

> What wasn't mentioned in that comment was that users should not be encouraged
> to remove information that is useful (see above). We're not removing the
> ability to do so, we're just not privileging it as much as we're privileging
> search. Putting the button on the dialog almost implies that it is something
> that the user should do often, and implies that it is the user's responsibility
> to keep the list clear (and indeed, previously had they not done so, they would
> have suffered for it in terms of performance when opening that list!). 

To my mind this is least weak justification for removing the Clear button, but
seems entirely based on the assumption that search (again, a brand new feature)
is the exclusive use case for the window. I, personally, would be satisfied
with the return of Clear with a popup and "don't show me this again" checkbox
that warned me with the above reasoning for not clearing the list.

> With the new backend design, sdwilsh assures that there is no performance
> impact to the list being long, especially as we chunk the display results. To
> control overall length, we might want to consider bug 251337 to implement the
> same sort of expiry/aging as exists in history.

I'm not convinced that this is relevant to whether the Clear All button is
retained or not.

> Removing UI is always contentious, and we've actually taken pains to replace it
> with *two* new alternative ways to achieve the same effect: unlike previous
> versions, you can now use the Clear List item on the shortcut menu, or select
> multiple entries and press del. Additionally, you can prune your list more
> intelligently: want to get rid of all the PDFs? Search, select, clear.

Reasons given above for the deficiencies in alternative #1.

For #2, this still lacks in discoverability but isn't as bad as #1.  

> I'm glad to see add-ons remain for people who wish to keep their list shiny and
> clean. I would also commend those users to the Clear Private Data entry for
> download history if they wish to keep that automated.

Rebuttal for why the addon route isn't a good solution is given above.

I, too, am not against search but I don't its current implementation trumps the
need for the return of Clear button.


    
  
Depends on: 251337

    
    

    
  
I would kindly ask that a final decision be made on this. 

I don't think much more new argument and points are going is going to be squeezed out of this bug before it's too late to implement. RC1 is fast on approach and if this button has an icon, then it's more than possible than the design team will want to design different versions for different Operating Systems.

So I would ask that a decision be made one way or another if it's going to land for Fx3 or not. Rather than people just let the bug run till it's too late to land.

    
    

    
  
(In reply to comment #107)
> So I would ask that a decision be made one way or another if it's going to land
> for Fx3 or not. Rather than people just let the bug run till it's too late to
> land.
 

The decision had been made. The decision was to go with what some "UI team" said to do and not what the users wanted. 

Who are they making this browser for anyway?

Maybe it's just my theme or that I'm on Kubuntu linux, but the UI for FF3 looks stock, stark and almost like framework looking. It's not polished in the least. And that may change once it's officially released and the package maintainers get their hands on making it look good.... but FF2 looks better than FF3. FF2 had polish. FF3 is still very rough looking, almost mock-up like.

I say that to backup my dissatisfaction with the job the UI team is doing. Removal of the Clear List button is the 2nd biggest UI difference that I've noticed in FF3 and the 2nd biggest UI difference that I don't like. The first being what I was speaking about above, the tool bars, buttons, tabs section.

    
    

    
  
Would lowering the timeout between each batch load of items when opening the download manager alleviate some of the complaints with how it stands? That seems to be a major reason put forward for proponents of this bug...

    
    

    
  
Its really late on a Friday night, and I'm going to think about this again tomorrow before I make a final decision for Firefox 3, but here's my basic thinking (obviously leaning towards not making late UI changes).

* The primary argument (I manage my files via the filesystem) suggests that there isn't a benefit for those users to retain information in the download manager at all.  I don't think I'm seeing an argument that follows the lines of "I need the information in the download manager until I clean up my download folder, and then I clean it up."  Most of the arguments I've seen in this bug are very much "I don't need this information, so I should be able to dump it quickly."  I think the "Remember what I've downloaded" pref is the answer to that concern, not a manual action that must be repeated frequently.

* Another form of that argument is "we don't track files being moved, so the information stops mattering."  Again, I don't think a big "delete data" button is the answer here.  What is worth discussing is the idea pruning entries where we have lost the local file reference.  We already are able to detect this for the context menu case, so it seems trivial to implement a lazy method to prune entries that are missing.  I don't think the overhead of nsIFile.exists() would be more than noise in the current UI code, so we could probably implement this pretty cleanly and just prune on window open.

* Third, the "what about performance?" concern is basically moot.  There does exist a possibility that in an edge case, a user with a wildly large number of downloads would get a large enough list that performance would suffer in a measurable form.  This is an extremely unlikely case, based on the current implementation and the tuning we've done to date.  We shouldn't design UI around extreme cases, in any case, and there is a secondary UI option to enable users to clear the list if they actually hit this.

* Finally, the whole purity of context menus argument is pretty bogus.  We've been breaking that for the tab context menu for longer than I've been working on the project, as an example.  The various HIGs are vague on the concept, but items like "sort" have always acted on the full list, and no one to my knowledge has ever complained about that behaviour breaking imaginary senses of propriety.  So I'm not going to give that argument any weight.

Ultimately, what I'm looking for here is not more debate, but concrete answers to the following questions:

* What is the expected harm to users if they fail to see the button and never clear their download history?  Does this affect anyone beyond an extreme case?  Please provide evidence, not assertion, that the harm is real.

* Why is a manual action preferred to an automatic one (flipping the pref, automatic cleanup of old and/or moved downloads, etc) to prevent this harm? (Requires a reasonable answer to the first question to matter)

* Why should that manual action belong to the primary UI?  Under what circumstances is this used frequently enough to justify the visual weight, that shouldn't be handled in an automatic manner?

    
    

    
  
(In reply to comment #110)
> * Third, the "what about performance?" concern is basically moot.  There does
> exist a possibility that in an edge case, a user with a wildly large number of
> downloads would get a large enough list that performance would suffer in a
> measurable form.  This is an extremely unlikely case, based on the current
> implementation and the tuning we've done to date.  We shouldn't design UI
> around extreme cases, in any case, and there is a secondary UI option to enable
> users to clear the list if they actually hit this.

Sync performance is awesome thanks to SQLite, I think what they're meaning is how items are batch-loaded after a timeout; it just so happens that this timeout is usually 300ms, and 300ms of doing nothing for every 3 items is a lot of waste.

If sdwilsh is still reading the bugmail of this bug (unlikely given the huge amount of spam lately); sdwilsh, would you support lowering the timeout? Something like 100ms or 50ms? I know a huge list is an edge case but it is still ridiculous to wait such a long period of time (in computing relativity) so often.

    
    

    
  
(In reply to comment #111)
> If sdwilsh is still reading the bugmail of this bug (unlikely given the huge
> amount of spam lately); sdwilsh, would you support lowering the timeout?
> Something like 100ms or 50ms? I know a huge list is an edge case but it is
> still ridiculous to wait such a long period of time (in computing relativity)
> so often.
Sadly, I care about the module too much to not read bugmail, even when my school workload dictates that I should.  I'd be OK with halving it, but I think anymore more is overkill.

    
    

    
  
(In reply to comment #110)
> * The primary argument (I manage my files via the filesystem) suggests that
> there isn't a benefit for those users to retain information in the download
> manager at all.

You're not reading what's written here, then. People use the download manager as an Inbox and clear it periodically, independent of session restart. They do this to make use of a short-ish list UI that is not a date-grouped tree widget, and then move longer-term downloads to directories managed and searched via the OS's UI, which is invariably richer than the download managers.

No more caricaturing this position into "there isn't a benefit at all." That is a straw man and it's not helpful given all the comments here contradicting it.

> * Another form of that argument is "we don't track files being moved, so the
> information stops mattering."  Again, I don't think a big "delete data" button
> is the answer here.  What is worth discussing is the idea pruning entries where
> we have lost the local file reference.

Irrelevant, but until you have that bug fixed, Clear All should stay.

> We already are able to detect this for
> the context menu case, so it seems trivial to implement a lazy method to prune
> entries that are missing.  I don't think the overhead of nsIFile.exists() would
> be more than noise in the current UI code, so we could probably implement this
> pretty cleanly and just prune on window open.

You are making some assertions here that need to be fixed bugs before any of this is reason to remove Clear All.

> * Third, the "what about performance?" concern is basically moot.

Again, read the comments just recently added about the batching meaning the scrollbar thumb shrinks slowly. The issue here is more perceived performance and real confusion due to the overlong list. If search is the model, then a list of hundreds of items is worse than useless -- it's misleading due to the unpurged renamed or removed files, and it gets in the way of finding the valid "Inbox" items -- and of course it demands a Clear All button to start over.

> * Finally, the whole purity of context menus argument is pretty bogus.  We've
> been breaking that for the tab context menu for longer than I've been working
> on the project, as an example.  The various HIGs are vague on the concept, but
> items like "sort" have always acted on the full list, and no one to my
> knowledge has ever complained about that behaviour breaking imaginary senses of
> propriety.  So I'm not going to give that argument any weight.

More dismissive assertions and two-wrongs-make-a-right arguing are poor reasons for any change.

> Ultimately, what I'm looking for here is not more debate, but concrete answers
> to the following questions:
> 
> * What is the expected harm to users if they fail to see the button and never
> clear their download history?  Does this affect anyone beyond an extreme case? 
> Please provide evidence, not assertion, that the harm is real.

You are not reading. Some users want a usably short "Inbox" for recent downloads, and these users rename long-term downloads using filesystem UI and find them with OS search. They need to Clear All, and aperiodically with respect to session restart.

Worse, users who don't know what the download manager is for will see that slowly shrining scrollbar thumb, and the overlong list, and these are not going to help them make use of Search or discover its date and URL features. On the contrary, the unusably long list that will inevitably result will make a dead zone in the UI.

> * Why is a manual action preferred to an automatic one (flipping the pref,
> automatic cleanup of old and/or moved downloads, etc) to prevent this harm?
> (Requires a reasonable answer to the first question to matter)

What are you talking about? There's no automatic answer for finding a download. Search may yield false positives. Those users who prefer the richer OS filing UI will use it and leave dead items in the list. These points have been made over and over. They mean that users have to take manual steps, in reality. 

There is no perfect automation, and smuggling the undemonstrated belief that Search provides such a thing into your demand for answers to questions already answered is just bad form.

> * Why should that manual action belong to the primary UI?

Because your untested dream-Search model does not fit reality for enough users, and it bids into existence manual intervention to deal with the overlong list that it inevitably creates. How about you respond to this argument, which I've made several times here (and in email recently)?

/be

    
    

    
  
(In reply to comment #113)
> (In reply to comment #110)
> > * Finally, the whole purity of context menus argument is pretty bogus.[snip]
> 
> More dismissive assertions and two-wrongs-make-a-right arguing are poor reasons
> for any change.

And (I meant to add) the main objection to Clear in the context menu is that it's undiscoverable. But apart from this, the "purity" argument should not be dismissed simply because Firefox doesn't follow HIGs or sane context menu rules in a few other places. Bugs don't justify more bugs.

/be

    
  
Depends on: 429614

    
    

    
  
I don't think that context menus that have options that act on more than the specific item in question are bugs.  The key word there is context.  The vista HIG explicitly talks about item or window region, since there's often items that operate in the larger context (the whole UI element, i.e. the list, or submenu) that are entirely correct, not bugs.  I was using them as illustrations of places where it isn't wrong, but doesn't meet the arbitrary constraint outlined by a number of people in the bug.  The classic example is Paste, which is enabled in many management UIs, including file browsers, even if something that isn't a container or a blank space is selected.

    
    

    
  
> * What is the expected harm to users if they fail to see the button and never
> clear their download history?  Does this affect anyone beyond an extreme case? 
> Please provide evidence, not assertion, that the harm is real.

From 5 years of technical support experience and UI studies, I can safely
assure you that about 10% of users never (or almost never) use context menus,
unless they know for sure that they must. This sounds unbelievable, but true.
(This, I think, is the exact reason because M$ designed a Save button to appear
in IE when an image is hovered, while a right-click item to save image existed
for ages.)

So the problem is that such users may never discover the way to clear the list
in a click; instead, they'll be doing that item by item. They won't be keeping
the list endlessly long because they've heard somewhere that they must clean
after themselves, as they do in real life, as that improves performance etc
(deleting files is the second task a novice user is taught, after learning
about files and folders). And, of course, "Clear Private Data" is not a
solution either, since none of novice users would click that for whatever
reason (just read it to learn why - it may be deleting all files in My
Documents?!).

The "Clear List" button, to the contrary, is associated with the download
manager itself, and seems therefore safe enough to click, and also it is
discoverable because it doesn't need a right click.

These unexperienced users also won't use Search; they don't understand it at
all, and they don't need it.


    
    

    
  
Does anyone here remember the delete button argument in gmail? It seems like a wonderful analogy here:

Developers said you didn't need an easily discoverable delete function as you never needed to delete anything because you can store pretty much indefinitely and there's a search

Delete was of course added in the end, because the gmail team presumably realised that you can't make all users follow your Utopian-search-model. Some users like to clear things out and a lot of these users need a discoverable delete buttons.

Now, I think just for the sheer number of users who that applied to, it's enough reason for there needing to be an easily discoverable "Clear List" button here. 

Personally (and I think this is worth putting, even though I'm not the standard user, I still think this is a very valid point) I do follow Google's Utopian-search-model. I love to search, I love the AwesomeBar. However, I do not love the download manager search bar, it "feels slow" (I know it's not really), it's not very effective at times (bug 429750), it doesn't refer to real files 95% of the time for me. Most download locations can be found using the AwesomeBar, my download files can be found using Google Desktop. So I still want clear list and in the Fx2 download manager, my 3 main actions (open, clear item, clear list) were all 1 button clicks, in Fx3 manager my 3 main actions still remain the same, but they're twice the click through, so anything which reduces the click through is great for me.

    
    

    
  
So the UX Team is the new M$?
They have obviously decided that our reasons are "invalid" and that they know what is best for us, even what we want. All this voting and complaining won't lead anywhere as long as no one will listen. Please end this hitlerism, and just implement the Clear List button.

About usage:
I guess this inbox-ish way of using the download manager applies to me as well. What I prefer to do is manually scan through my most recent downloads and then clear my list.

    
    

    
  
I wanted to bring up a point that no one has mentioned yet. Is Mozilla/Firefox still open-source? I ask this because isn't one of the foundations of Open-Source to be "Free As in speech" and/or "A Bazaar as opposed to a cathedral" or: "Listen to your users". Every post here made by a non-Mozilla employee seems to want the Clear List button back (or a different way to implement some things, but that's almost another discussion entirely). Give the people what they want. It's users like us who got Firefox up to a 28% market share, the users that don't know what they want...Well...They're exactly that...Users that don't know that they want search and might think of the "Clear List" button as such a trivial thing and will probably miss it when it's gone. All i'm saying is stop thinking you all know what is best and "Oh, 'Usability Experts' said this" and "Perf tests show this". Give the users (the only ones that are being vocal...As i said, i can't find ANY non-mozilla people who like the button being gone) what they want or really, you're no better than MS...and that's just a travesty as Mozilla/Firefox was supposed to kind of be the savior of the browsers.

    
    

    
  
(In reply to comment #113)
> You're not reading what's written here, then. People use the download manager
> as an Inbox and clear it periodically, independent of session restart. They do
> this to make use of a short-ish list UI that is not a date-grouped tree widget,
> and then move longer-term downloads to directories managed and searched via the
> OS's UI, which is invariably richer than the download managers.
I don't think this is your point, but I keep reading this reasoning as "there's a subset of our users who use the DM as an inbox, and we must accommodate them regardless of how representative they are of our entire user base.

> Again, read the comments just recently added about the batching meaning the
> scrollbar thumb shrinks slowly. The issue here is more perceived performance
> and real confusion due to the overlong list. If search is the model, then a
> list of hundreds of items is worse than useless -- it's misleading due to the
> unpurged renamed or removed files, and it gets in the way of finding the valid
> "Inbox" items -- and of course it demands a Clear All button to start over.
On my macbook it stops shrinking after ~5 seconds.

(In reply to no comment in particular)
Are people actually arguing from an HCI perspective here, or are they arguing based on personal preference?  I'm banking on the latter simply due to the amount of name calling and attacks by many comments...

    
    

    
  
(In reply to comment #110)
[...]
> I don't think I'm seeing an argument that follows the lines of
> "I need the information in the download manager until I clean up my download
> folder, and then I clean it up."
[...]
> * What is the expected harm to users if they fail to see the button and never
> clear their download history?  Does this affect anyone beyond an extreme case? 
> Please provide evidence, not assertion, that the harm is real.
> 
> * Why is a manual action preferred to an automatic one (flipping the pref,
> automatic cleanup of old and/or moved downloads, etc) to prevent this harm?
> (Requires a reasonable answer to the first question to matter)
> 
> * Why should that manual action belong to the primary UI?  Under what
> circumstances is this used frequently enough to justify the visual weight, that
> shouldn't be handled in an automatic manner?
> 

Maybe you haven't seen my comment #100, but the reason I prefer cleaning the list manually (and, if possible, via a button in the download manager) is because I want to see all downloads of the current "downloading session" without the "noise" of earlier downloads. As long as one of these "current" downloads is not finished, I want to see them all, because they belong together. Once they are all finished, I will clear the download manager (manually) and do whatever I'm going to do next with these downloads.

It isn't that the absence of the button is "harming" me, it's rather that its presence is helping me get rid of "past info which I don't need anymore" at the exact time when I've finished using it, and not a minute earlier or later. If other people want never to empty their Download Manager, AFAIK the presence of a "Clear List" button which they never use wouldn't "harm" them, and I'm not against the existence of a preference somewhere to make that button disappear, as long as I am allowed not to use it.

AFAICT, the only people "harmed" by the presence of a "Clear List" button are those whose standing is "I never clear my download list, and neither should anyone be allowed ever to clear his, or else only by jumping through hoops". I regard THAT standing as telling me what I may or may not do, i.e., an encroachment of my liberty.

    
    

    
  
> I don't think this is your point, but I keep reading this reasoning as "there's
> a subset of our users who use the DM as an inbox, and we must accommodate them
> regardless of how representative they are of our entire user base.

This point has already been stated. Please read comment #94 more carefully:

"
>> I think
>> the resistance is coming mostly from not wanting to succumb to the will of a
>> vocal minority of bug-commenters
>
> This is bogus. Sorry, it's a trap that I can understand front end folks falling
> into, given the bad manners of some complaining parties here (Chris Alvares,
> you can remove yourself from the cc: list or be quiet -- other behavior of the
> comment 92 kind is not helpful and it's not welcome). But it is completely
> irrelevant.
"


> On my macbook it stops shrinking after ~5 seconds.
> 
> (In reply to no comment in particular)
> Are people actually arguing from an HCI perspective here, or are they arguing
> based on personal preference?  I'm banking on the latter simply due to the
> amount of name calling and attacks by many comments...
> 

Well it tales 15 seconds on my PC and I'm not a big downloader and I had to test the clear private data function several times, so I imagine it would grow to a much bigger number than that.

    
    

    
  
> > * Why should that manual action belong to the primary UI?
> 
> Because your untested dream-Search model does not fit reality for enough users,
> and it bids into existence manual intervention to deal with the overlong list
> that it inevitably creates. How about you respond to this argument, which I've
> made several times here (and in email recently)?
> 
My downloads go into a downloads folder (default on 10.5 and Vista) or I individually target to specific folders.  Thus I rarely rename these files.  My scrollbar does shrink (takes 10-15s on my MBP) - but I can say until I read this bug I didn't notice this. So this model works just fine for me.   I'd note this shipped in several betas to 1M+ users, 9,999,950 or so of which we haven't heard from yet in this bug.  

How do you define 'enough users' for either set of users? 

    
    

    
  
(In reply to comment #123)
> > > * Why should that manual action belong to the primary UI?
> > 
> > Because your untested dream-Search model does not fit reality for enough users,
> > and it bids into existence manual intervention to deal with the overlong list
> > that it inevitably creates. How about you respond to this argument, which I've
> > made several times here (and in email recently)?
> > 
> My downloads go into a downloads folder (default on 10.5 and Vista) or I
> individually target to specific folders.  Thus I rarely rename these files.  My
> scrollbar does shrink (takes 10-15s on my MBP) - but I can say until I read
> this bug I didn't notice this. So this model works just fine for me.   I'd note
> this shipped in several betas to 1M+ users, 9,999,950 or so of which we haven't
> heard from yet in this bug.  
> 
> How do you define 'enough users' for either set of users? 
> 

Er - make that 999,950 - wasn't trying to inflate the numbers :-).  I'm somewhat ambivalent to the final outcome - I just wanted to point out that I think we have to be very careful when assuming as certain use case is most common for a large user group.



    
    

    
  
(In reply to comment #123)
>  I'd note
> this shipped in several betas to 1M+ users, 9,999,950 or so of which we haven't
> heard from yet in this bug.  
> 
> How do you define 'enough users' for either set of users? 
> 

This point has already been stated. Please read comment #94 more carefully:

"
>> I think
>> the resistance is coming mostly from not wanting to succumb to the will of a
>> vocal minority of bug-commenters
>
> This is bogus. Sorry, it's a trap that I can understand front end folks falling
> into, given the bad manners of some complaining parties here (Chris Alvares,
> you can remove yourself from the cc: list or be quiet -- other behavior of the
> comment 92 kind is not helpful and it's not welcome). But it is completely
> irrelevant.
"

But to add my own personal view on this:

* Most people just use software, they don't provide
* Most people who provide feedback on software complain about on some random forum
* Most people who provide feedback and put it in a useful place tend to be power users and have extensions or adopt new methods of using software pretty much instantly
* Most people who provide feedback, put it in a useful place, like using their old methods of UI and are willing to actually make a bug or an issue about it, get instantly dismissed by developers (certainly in this case) so give up instantly

    
    

    
  
P.S my first point should of course been:

* Most people just use software, they don't provide feedback
And to inject another point:
* Most people who use Firefox beta don't provide feedback

    
    

    
  
(Apologies for this being off-topic to this bug, but it is still related to the
issue at hand.)

Shawn Wilsher said way back in comment 37 that the decision to restore the
"Clear List" button would be partially based on the popularity of the "Clear
Download List" add-on on AMO (see URL field). Just from my experience testing
it, it seems to work perfectly and it even has the icon, too.

However, for it to be a fair indication of how many users really want the
"Clear List" button back, the add-on needs to be public and not in the sandbox.
Given the large outcry over the loss of this feature and the impending
deadlines for RC1, could the AMO review process be expedited for that add-on so
that it can become public sooner rather than later?

Also, there is another add-on named "Clear Download List" on AMO
(https://addons.mozilla.org/en-US/firefox/addon/7049) so I think the number of
downloads of that add-on should be considered as well as downloads of the one
by Mrtb.

    
    

    
  
(In reply to comment #126)
> P.S my first point should of course been:
> * Most people just use software, they don't provide feedback
> And to inject another point:
> * Most people who use Firefox beta don't provide feedback

Actually this relates to your last point.

> * Most people who provide feedback, put it in a useful place, like using 
> their old methods of UI and are willing to actually make a bug or an issue
> about it, get instantly dismissed by developers (certainly in this case) so 
> give up instantly

I've provided quite a bit of feedback both here and at Mozillazine and I
usually get treated like I haven't enjoyed the same koolaid they have so my
opinion doesn't matter. Which is precisely why I'm looking at other Linux web
browsers. Somewhere between when Fx2 came out and now the devs seem to have
changed their attitude from "Let's make this a great browser for everyone to
use." to "We're making the browser we want to use. If you don't like it,
there's the door. We sure don't need you." The amazing thing is that much of
the community is truly interested in our issues. It's just a few (addon devs as
well as Moz devs) that act the second way. But all it takes is one person to
routinly treat us like our opinion doesn't matter for use to decide reporting a
bug, or commenting on an open bug, just isn't worth the time or effort.

I'm still keeping up with this bug because it became the straw that broke this
camel's back (see, it's not a totally OT comment) and I hate the fact that I feel like Firefox doesn't care what ALL of the users have to say anymore. And for some weird reason I'm hoping someone will show me that we do have a place in the bigger Mozilla community.

    
    

    
  
> (In reply to comment #123)
> >  I'd note
> > this shipped in several betas to 1M+ users, 9,999,950 or so of which we haven't
> > heard from yet in this bug.  
> > 
> > How do you define 'enough users' for either set of users? 
> > 
> 
> This point has already been stated. Please read comment #94 more carefully:
> 

My comment was in reference to the assertion in comment 123 that the search model didn't work for enough users.  I was just asking how the determination of enough was made. 

    
    

    
  
(In reply to comment #129)
> > This point has already been stated. Please read comment #94 more carefully:
> > 
> 
> My comment was in reference to the assertion in comment 123 that the search
> model didn't work for enough users.  I was just asking how the determination of
> enough was made. 
> 

Well as comment #113 and others state, there needs to be evidence to show that search is good enough to replace to remove the clear list, not the other way around. 

    
    

    
  
(In reply to comment #127)
> However, for it to be a fair indication of how many users really want the
> "Clear List" button back, the add-on needs to be public and not in the sandbox.
> Given the large outcry over the loss of this feature and the impending
> deadlines for RC1, could the AMO review process be expedited for that add-on so
> that it can become public sooner rather than later?
Out of sandbox.

> Also, there is another add-on named "Clear Download List" on AMO
> (https://addons.mozilla.org/en-US/firefox/addon/7049) so I think the number of
> downloads of that add-on should be considered as well as downloads of the one
> by Mrtb.
Someone should contact that add-on author and let him know there's already an add-on out there that does what his does.

    
    

    
  
(In reply to comment #130)
> (In reply to comment #129)
> > > This point has already been stated. Please read comment #94 more carefully:
> > > 
> > 
> > My comment was in reference to the assertion in comment 123 that the search
> > model didn't work for enough users.  I was just asking how the determination of
> > enough was made. 
> > 
> 
> Well as comment #113 and others state, there needs to be evidence to show that
> search is good enough to replace to remove the clear list, not the other way
> around. 
> 

Why is evidence required in one case but not the other? 

    
    

    
  
(In reply to comment #130)
[...]
> Well as comment #113 and others state, there needs to be evidence to show that
> search is good enough to replace to remove the clear list, not the other way
> around. 

Also, why not have both? Even if some users never "clear" and if others (or maybe some of the same) never "search", how would they be, as mconnor put it, "harmed" by the presence of a widget they never use?

    
    

    
  
(In reply to comment #132)
> 
> Why is evidence required in one case but not the other? 
> 

Please read Brendan Eich (CTO of the Mozilla Corporation) comments more carefully and you'd understand that. In this case comment #103.


(In reply to comment #133)
> Also, why not have both? Even if some users never "clear" and if others (or
> maybe some of the same) never "search", how would they be, as mconnor put it,
> "harmed" by the presence of a widget they never use?
> 

This is common mistake people are repeating in this bug, no one is asking for search to be removed and you'd realise that, especially if you read Brendan Eich comments more carefully.

    
    

    
  
(In reply to comment #134)
[...]
> (In reply to comment #133)
> > Also, why not have both? Even if some users never "clear" and if others (or
> > maybe some of the same) never "search", how would they be, as mconnor put it,
> > "harmed" by the presence of a widget they never use?
> > 
> 
> This is common mistake people are repeating in this bug, no one is asking for
> search to be removed and you'd realise that, especially if you read Brendan
> Eich comments more carefully.
> 

My question remains: how would people be "harmed" by a widget they never use?

    
    

    
  
(In reply to comment #135)
> (In reply to comment #134)
> [...]
> > (In reply to comment #133)
> > > Also, why not have both? Even if some users never "clear" and if others (or
> > > maybe some of the same) never "search", how would they be, as mconnor put it,
> > > "harmed" by the presence of a widget they never use?
> > > 
> > 
> > This is common mistake people are repeating in this bug, no one is asking for
> > search to be removed and you'd realise that, especially if you read Brendan
> > Eich comments more carefully.
> > 
> 
> My question remains: how would people be "harmed" by a widget they never use?
> 

Sorry, I'm clearly not understanding your question, I don't see what relevance it has to this bug. I have nothing against the search box being there. But my answer to that, is the standard Firefox moto "don't have unused UI, it clutters space". But I don't think it would go unused.


Chatting on the Firefox IRC channel, people seemed a little gobsmacked about my comment #134. I'm sorry if it seemed curt, but I'm quite eager to get a decision on this one way or the other, I don't want the excuse that it's too late to ship, so I didn't want to repeat discussions already made. Also as I pointed out in IRC, what authority do I have to question the VP of Engineering at Mozilla when I can refer to points made by the Chief Technology Officer at Mozilla.

    
    

    
  
 > Chatting on the Firefox IRC channel, people seemed a little gobsmacked about my
> comment #134. I'm sorry if it seemed curt, but I'm quite eager to get a
> decision on this one way or the other, I don't want the excuse that it's too
> late to ship, so I didn't want to repeat discussions already made. Also as I
> pointed out in IRC, what authority do I have to question the VP of Engineering
> at Mozilla when I can refer to points made by the Chief Technology Officer at
> Mozilla.

Reasoned discussion on the merits shouldn't bow to titles.  I had read all the posts you link to and was trying to raise a process issue.  I'm going to drop this now since I'm assisting in taking this bug further off topic.

    
    

    
  
"Clear All" is the back button of the download manager.

    
    

    
  
(In reply to comment #119)
> I wanted to bring up a point that no one has mentioned yet. Is Mozilla/Firefox
> still open-source? I ask this because isn't one of the foundations of
> Open-Source to be "Free As in speech" and/or "A Bazaar as opposed to a
> cathedral" or: "Listen to your users". Every post here made by a non-Mozilla
> employee seems to want the Clear List button back (or a different way to
> implement some things, but that's almost another discussion entirely).

I'm a Mozilla employee and I want Clear back for specific reasons I've given over and over, so be careful generalizing.

Leaving out the Mozilla employee statement, your point is ok up to a point as a general reminder to listen to users, but it falls down as it begs questions of how representative dissenting comments here are of "the people".

This is the question sdwilsh tries to raise in comment 120 without any evidence one way or the other -- i.e., for his apparent belief that the dissenters are a tiny minority who can be ignored. That kind of assumption is also not kosher.

The fact is we've had a Clean Up or Clear List or whatever button for all Firefox final releases. The performance problems of long lists in the past were not the reason it was useful to some users, so fixing those perf probs (or mitigating them) did not remove the utility of Clear. Likewise, Search is great when it works well, but it's not the only usage model, it has its limits, and it can't compete with OS or desktop search once files move.

We don't know the breakdown of populations by use-case, but we do know that Clear was there in some form, and some people used it.

We also know now that the reasons for removing it are flawed, because they assume (a) people use Clear only because of the long-list performance bug, or for no good reason at all; (b) people should suffer the loss of Clear in order to make them learn to use Search (and then ignore the unusably long list that takes up space in the download manager).

We also know bugs impairing Search effectiveness remain unfixed.

Taken together, these facts are enough to cause a crisis of confidence (obvious, there's no point in denying it) that must be repaired by module owner responses that are not dismissive, not forms of circular arguing, and not assumptions about user population size.

/be

    
  
Flags: blocking-firefox3- → blocking-firefox3?

    
    

    
  
This awful "DELTE DATA" button could easily have a warning the first few time, have a red outline around it and flash warning signs for all I care. If you're scared people will accidentally click it, you know how to deal with those situations.

I haven't downloaded anything for 2 days. My list is clear. If I download 1 file tonight, I will clear my list after the file is done. An automatic way of clearing this list doesn't really help, me. I want to see that the file is done, then I can clear it. Yes a lot of that is personal preference, but that's the only first hand "example" I can give.

We can't ask everyone every time a change like this comes around. I know several tech support people, and I didn't poll them officially but any time I see their download manager, it's downloading one thing and the rest is clear.

My family used to run FF2 and had a clearish download history. They've been on FF3 for about a month now and the list is huge.  If the function was a primary one of the window, I think their download history would be cleared. Not because they think they have to, but because I've never heard ANYONE using the download history for what it seems to be intended for. And by anyone, I'm encompassing about 20-25 people with that.

I'll ask the other techs at work on monday and report back here.

    
    

    
  
(In reply to comment #120)
> (In reply to comment #113)
> > Again, read the comments just recently added about the batching meaning the
> > scrollbar thumb shrinks slowly. The issue here is more perceived performance
> > and real confusion due to the overlong list. If search is the model, then a
> > list of hundreds of items is worse than useless -- it's misleading due to the
> > unpurged renamed or removed files, and it gets in the way of finding the valid
> > "Inbox" items -- and of course it demands a Clear All button to start over.
> On my macbook it stops shrinking after ~5 seconds.
> 
> (In reply to no comment in particular)
> Are people actually arguing from an HCI perspective here,

HCI.

> or are they arguing
> based on personal preference?  I'm banking on the latter simply due to the
> amount of name calling and attacks by many comments...

Nice try, but as far as I can tell the anger is because of recurring failure to respond to specific points, which you repeated right here. "On my macbook it stops shrinking after ~5 seconds" is irrelevant in response to the main point you cited:

> > ... misleading due to the unpurged renamed or removed files, and it gets in
> > the way of finding the valid "Inbox" items....

Constructive suggestion: the download manager should auto-delete UI-items where the file has been removed or renamed, but keep the backing-store item, at least its URL and download date, in the search corpus. This would relieve my Clean Up or Clear List needs.

/be

    
    

    
  
(In reply to comment #141)
> Constructive suggestion: the download manager should auto-delete UI-items where
> the file has been removed or renamed, but keep the backing-store item, at least
> its URL and download date, in the search corpus. This would relieve my Clean Up
> or Clear List needs.
Bug 430000 would make the default list only show files that exist while letting you search for old downloads.

Here's a build to try out with various patches:
https://build.mozilla.org/tryserver-builds/2008-04-21_00:39-edward.lee@engineering.uiuc.edu-only.exists/

Bug 430000 - Only show files that exist by default; search all downloads for search
Bug 251337 - Download manager history should have "aging" option, just like the browser history
Bug 423718 - Use native platform colors for URLs in the location bar autocomplete, make the line between rows lighter
Bug 429531 - Location bar should show non-word-boundary matches below word-boundary matches
Bug 392143 - show keywords as url bar autocomplete choices
Bug 249468 - Add all bookmark keywords to location bar autocomplete drop-down list
Bug 422698 - different levels of URL decoding for address bar and autocomplete suggestions
Bug 424717 - Location bar autocomplete should be willing to complete to a URL with a different protocol
Bug 424509 - Location bar autocomplete favors "http://" over domain name starting with "h"
Bug 395161 - Make it possible to restrict the url bar autocomplete results to bookmarks/history entries and match only url/title/tags
Bug 424557 - Allow AwesomeBar to default search only urls (or history/titles/bookmarks/tags)
Bug 420437 - Search and emphasize quoted strings with spaces
Bug 414326 - Use DownloadUtils for software update downloads
Depends on: 430000

    
    

    
  
I'm a little worried about privacy concerns with Bug 430000, say someone has downloaded 50 things and only 5 things are showing, the user deletes those 5 things thinking the download manager is cleaned. Someone searches the now blank download manager and finds old items.

Perhaps a dialogue box asking upon the deletion of the last visible item if all download history items want to be deleted. Or perhaps a button which toggles between viewing or not viewing history items. I'm sure UI people know how to deal with that better than me, but I do think it's a concern.

Also, as the bugs blocking this bug seem to be a general attempt to get around doing this bug (and if bug 430000 is done well AND lands for Fx3 RC1 this goes a long way to doing that in my opinion), it seems that the select all function should work properly, which at the moment it really doesn't as per bug 429977.

    
    

    
  
If deletion of downloaded items will only hide them from view but leave them exposed to search, this will be a great privacy issue. Why all this magic? If one needs a download history, let him be smart enough not to clear the list each time.
Assignee: edilee → beltzner
Status: REOPENED → NEW
Flags: blocking-firefox3? → blocking-firefox3+
Whiteboard: [see comment 52 for UX decision]

    
    

    
  
My 2 cents: I think the main argument for having this button in the download manager is because people are used to having it there. The list is long now. It full of richlist items which are large, and (in my opinion) aren't designed well for showing this many items (for a counter example, see how Outlook groups its long richlist so that it looks ordered and you can collapse items you don't want to view, and even it isn't perfect by a long shot). I'd say that the extensions dialog faces this same problem when you install a lot in it.

The result is something that looks messy and overwhelming, even with only 50 or so items. In order to clear up the clutter, users are expected to search when all they really want is to be able to see when something is done/click on it and load the file. Maybe a better solution is to offer a few radios at the top of the dialog. "Current/Paused downloads", "Old downloads", "Recently finished downloads", etc. That way users don't have to deal with the clutter, but they're still not losing information.

I know its most likely to late to propose that, but I think in the absence of something that isn't going to annoy FF2 users (and I think this change is annoying at times), that we shouldn't remove/hide old functionality from them.
Flags: blocking-firefox3+ → blocking-firefox3?

    
    

    
  
I would remind people that unless they have *new* arguments, please do not spam this bug. It's been re-opened, and now people are (accidentally) resetting flags. The bug is blocking, that means it will be resolved before Firefox 3 ships.
Flags: blocking-firefox3? → blocking-firefox3+

    
    

    
  

      
      
      
      

        Attached patch
          
          
        v2 (obsolete)
        — 
          — Splinter Review
      

    


  
Assignee: beltzner → edilee

        Attachment #285617 -
        Attachment is obsolete: true

        Attachment #300038 -
        Attachment is obsolete: true
Status: NEW → ASSIGNED

        Attachment #317031 -
        Flags: review?(sdwilsh)

    
    

    
  

      
      
      
      

        Attached image
          
        screenshot of v2.1
        — 
      

    


  
Minor change from v2 to v2.1 for os x button styling.

    
    

    
  
To make some points clear:

* The most convincing argument for preserving the button within the current design is to minimize disruption for upgrading users.  It may be unnecessary (subjectively, at least), but some users want it, and there is substantial value in not forcing users into changing their habits, regardless of whether we agree that those habits are positive.  We're already asking a lot of people to accept significant and far-reaching change elsewhere in the UI, and this isn't as clear of a value proposition, and we recognize that the value of minimal disruption outweighs the benefits of retaining the data.

* The discussion in this bug has veered far past the norms of bugzilla etiquette, and often devolved into rampant advocacy and accusations.  The signal to noise ratio has been quite poor, and some people have made repeated comments that added nothing to the discussion.  I hope that is at an end.  The decision being made here was not because of the volume of advocacy comments, but in spite of the tendency of that sort of comments to drive people into defensive postures.  I hope we can all keep that in mind in the future.

* There is a lot of work to do around crisply defining all of the use cases we wish to support, and how those interact with the Library views of a user's overall history and also with the filesystem itself.  There is also work to be done to ensure that we retain a high signal to noise ratio throughout the UI in general, and we will pursue those with the aim of minimizing the necessity for users to manually clean up after themselves.  The future of the button depends entirely on whether enough users continue to use it once it is truly unnecessary.

* There is a wide gulf between "actions that are required for 'optimal' functionality" and "actions that users may wish to perform, even if not optimal" that often creates conflict in design discussions.  Historically, we have focused nearly all designs on the former, with little consideration for the latter.  Now that we have a mature and established project, we need to address both explicitly, recognizing that upgrading users represent a massive block of our future users, while still striving for a simple and task-driven UI.  I accept that I haven't spent enough time considering that angle, and I will do better in the future.

    
    

    
  

      
      
      
      

        Attached patch
          
          
        v2.1 (obsolete)
        — 
          — Splinter Review
      

    


  
mconnor: Shawn said to poke you instead of him ;)

1) clearDownloadList moved out of gDownloadViewController's doCommand stuff so extensions can change the function
2) Additionally, don't do clearList with performCommand('cmd_clearList') because performCommand is supposed to be for selected download items
- this doesn't need the gPerformAllCallback because it doesn't go through performCommand

        Attachment #317031 -
        Attachment is obsolete: true

        Attachment #317045 -
        Flags: review?(mconnor)

        Attachment #317031 -
        Flags: review?(sdwilsh)
Whiteboard: [has patch][needs review mconnor]

    
    

    
  
Re comment 149 ...

Well said. I would also add (with a slight soupcon of mea-culpa) that the resulting design which caused the furor was due to a half-completed implementation, and assumptions of behavioural shifting without evidence in hand, which is somewhat sloppy - points to that effect were convincing. 

Also note that I still firmly believe that fixing things like being able to select all entries and press "delete" as well as removing old entries like we remove history will obviate the need for an explicit "clear all" function. Still, that behavioural modification will take time, and we shouldn't skip ahead to the expected resulting change in behaviour without being sure it will take place.

    
    

    
  

      
      
      
      

        Attached patch
          
          
        v2.2 (obsolete)
        — 
          — Splinter Review
      

    


  
Additionally remove clear list from the context menus. (And update the test that makes sure clear list only clears the visible list.)

        Attachment #317045 -
        Attachment is obsolete: true

        Attachment #317153 -
        Flags: review?(mconnor)

        Attachment #317045 -
        Flags: review?(mconnor)

    
    

    
  
Edward, you *must* add an icon for this button under Gnomestripe. It does the action of clearing and as such it needs the broom icon (or whatever the theme uses for a clear metaphor) to follow HIG.

Add this to #clearListButton:

list-style-image: url("moz-icon://stock/gtk-clear?size=button");

    
    

    
  
Also, is there already an open bug to lower the batch timeout when loading the download list?

    
    

    
  

      
      
      
      

        Attached patch
          
          
        v2.3
        — 
          — Splinter Review
      

    


  
(In reply to comment #153)
> Add this to #clearListButton:
> list-style-image: url("moz-icon://stock/gtk-clear?size=button");
Done.

(In reply to comment #154)
> Also, is there already an open bug to lower the batch timeout when loading the
> download list?
Perhaps bug 413209.

        Attachment #317153 -
        Attachment is obsolete: true

        Attachment #317169 -
        Flags: review?(mconnor)

        Attachment #317153 -
        Flags: review?(mconnor)

    
    

    
  
Comment on attachment 317169 [details] [diff] [review]
v2.3

r=me
ui-r=beltzner on IRC
a=me

        Attachment #317169 -
        Flags: ui-review+

        Attachment #317169 -
        Flags: review?(mconnor)

        Attachment #317169 -
        Flags: review+

        Attachment #317169 -
        Flags: approval1.9+
Whiteboard: [has patch][needs review mconnor] → [has patch][has reviews]

    
    

    
  
http://hg.mozilla.org/cvs-trunk-mirror/index.cgi/rev/a8cbcd13b000
http://hg.mozilla.org/mozilla-central/index.cgi/rev/a8cbcd13b000

Checking in toolkit/mozapps/downloads/content/downloads.js;
/cvsroot/mozilla/toolkit/mozapps/downloads/content/downloads.js,v  <--  downloads.js
new revision: 1.149; previous revision: 1.148
done
Checking in toolkit/mozapps/downloads/content/downloads.xul;
/cvsroot/mozilla/toolkit/mozapps/downloads/content/downloads.xul,v  <--  downloads.xul
new revision: 1.51; previous revision: 1.50
done
Checking in toolkit/mozapps/downloads/tests/browser/browser_cleanup_search.js;
/cvsroot/mozilla/toolkit/mozapps/downloads/tests/browser/browser_cleanup_search.js,v  <--  browser_cleanup_search.js
new revision: 1.2; previous revision: 1.1
done
Checking in toolkit/themes/gnomestripe/mozapps/downloads/downloads.css;
/cvsroot/mozilla/toolkit/themes/gnomestripe/mozapps/downloads/downloads.css,v  <--  downloads.css
new revision: 1.10; previous revision: 1.9
done
Checking in toolkit/themes/pinstripe/mozapps/downloads/downloads.css;
/cvsroot/mozilla/toolkit/themes/pinstripe/mozapps/downloads/downloads.css,v  <--  downloads.css
new revision: 1.28; previous revision: 1.27
done
Checking in toolkit/themes/winstripe/mozapps/downloads/downloads.css;
/cvsroot/mozilla/toolkit/themes/winstripe/mozapps/downloads/downloads.css,v  <--  downloads.css
new revision: 1.31; previous revision: 1.30
done
Status: ASSIGNED → RESOLVED
Closed: 16 years ago → 16 years ago
Resolution: --- → FIXED
Whiteboard: [has patch][has reviews]
Target Milestone: --- → Firefox 3

    
  
Keywords: regression

    
    

    
  
I've see these bugs on this new bugged patch:

1. The new clear list button is always active
2. It hasn't an icon
3. It is on the left side of the searchbar (instead of the right one)

to see how it have to be, see my addon https://addons.mozilla.org/en-US/firefox/addon/6945

    
    

    
  
Please file new bugs if you have concerns about how the Clear List button looks/works instead of commenting here.
URL: https://addons.mozilla.org/en-US/fire...

    
  
Depends on: 430477

    
    

    
  
Verified FIXED using

Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9pre) Gecko/2008042304 Minefield/3.0pre

Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.4; en-US; rv:1.9pre) Gecko/2008042304 Minefield/3.0pre

-and-

Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9pre) Gecko/2008042305 Minefield/3.0pre

in-litmus+, too:

https://litmus.mozilla.org/show_test.cgi?id=5282
Status: RESOLVED → VERIFIED
Flags: in-litmus+

    
  
Depends on: 430486

    
    

    
  
To prevent accident clicking, have a dialog come up.

"Are you sure you wish to remove all your download history? This cannot be undone. (Yes/No)"

    
    

    
  
(In reply to comment #161)
> To prevent accident clicking, have a dialog come up.
> 
> "Are you sure you wish to remove all your download history? This cannot be
> undone. (Yes/No)"
> 

See Bug 430477 
Depends on: 431371
Product: Firefox → Toolkit

          You need to log in
          before you can comment on or make changes to this bug.
        






  

    
  







  

    

      
Attachment

      

      
      
      
      
    

    

      

        

          

            
General

            

              Creator: 



            

            
Created: 

            
Updated: 

            
Size: