I just updated my tree and the download manager pref panel, which was one of the best features of the download manager, has disappeared. STEPS TO REPRODUCE 1. Open Edit, Preferences. 2. Look for a "Downloads" panel in the "Navigator" section. EXPECTED RESULTS A panel should be present giving you the option to either download by using progress windows (the default, most convenient for casual users), or to download by popping up the download manager window (most convenient for people downloading occasional large files), or to download in the background (most convenient for people downloading lots of files, like me). ACTUAL RESULTS No pref panel.

This is not implemented yet, actually.. Over to default owner.

heh, it was in the 3/20 verif bits, but it's no longer in the 3/21 verif bits. blake, didja remove it to continue working on it? or, something else?

okay, the download mgr no longer automatically appears as of today's bits, so i can see why the pref panel might've pulled out for the nonce...

Bill asked that I remove it until there is more discussion about it.

I found it extremely useful. I liked the option of being able to switch between the different download display methods. I was a little shocked to discover that it wasn't part of the latest build. If it's not going to be reinstated, can you list the prefs.js entries that that the UI set so I can still change behaviour if I wish?

I imagine it will be back soon, right?

> can you list the prefs.js entries that that the UI set so I can still change > the behaviour if I wish? Is the download manager still functional? If so browser.downloadmanager.behavior is what you want. 0,1,2 corresponding to the three choices formerly available.

*** Bug 132791 has been marked as a duplicate of this bug. ***

Where's the spec for this? Where's the discussion?

Marlon is putting together a spec for this and then I will post it to the newsgroups.

This is feature creep, and today is UI freeze. IE Mac has no need for such prefs, I think we can live without them in our first cut DL mgr.

This isn't feature creep, it was already in!!!

Of course it's not feature creep; it is the only way for a user to get the Download Manager to automatically appear when they start a download. Having to bring it up manually is stilly, especially since you also have to have the normal progress window open at the same time.

Whether it was in or not is irrelevant, it is unnecessary. The DL manager should just appear, like the progress window used to. We don't need a new pref panel for this.

More stuff can be added to the download pref panel, such as allowing users to decide where downloads should go by default. I assume that was the thought by adding this to it's own pref.

nsbeta1- per Nav triage team. ->1.2

trudelle: you may think the download manager should appear, but, with all due respect, you are not the only user. I am aware of at least two other users who hate that behaviour -- one is me (I don't want _any_ new windows when I start a download) and another is one of my flatmates (he wants the old style progress windows so that he can see the progress of each one in the task bar on Windows). Since this has *already* been implemented, pushing it back is stupid.

So we've away users tried and true progress windows and replaced it with a new and untested download manager and not let users in the know adjust this? This is silly. One of the reasons I helped get this approved was because it came with a choice to use the old behavior in case the new experimental one had problems. Without this pref landing I don't feel at all comfortable about having given an approval to the download manager.

Yes, Andre, the reason this panel was added was because we knew of many worthwhile prefs to be added in the future, such as default download directory. I can't tell if the issue here is the addition of a pref panel or the addition of a pref itself. I do not agree that we don't need a pref for this, and I'm the first to fight new pref additions. I don't believe "silent downloading," that is, downloading without popping up or focusing a window, is a hard concept to grasp for competent users. It is not overly geeky, and it is useful. This had UE's hasty blessing, and Marlon was going to try to design a quick spec for this behavior. I'm going to attach the work I did for this and reassign to nobody. If someone else would like to drive my patch through r/sr/a/ui/ui freeze/whatever processes and get it in, they can.

Actually, I don't have the patch anymore. But it's in bug 131762 and cvs (pull the old revisions). -> nobody

But they don't have *these* prefs, nor were these prefs in the design spec for this feature, which has been available about 8 months now. You can call this stupid and silly all you want, but you cannot in good conscience justify adding such UI to the product after feature complete, after UI freeze, with no design or review, just because you can identify a handful of people in a bug who claim they need it. Adding features in such a manner is the hallmark of out of control bloatware. This is not about what I personally want; that doesn't matter at all. This is about what we need in the browser, and right now we need bugfixes, not more pref panels.

> But they don't have *these* prefs I was merely showing that your previously stated opinion, "We don't need a new pref panel for this", is not shared by other browser makers. > nor were these prefs in the design spec for this feature, These prefs had the explicitly go-ahead from Netscape and Mozilla UE people. > you cannot in good conscience justify adding such UI to the product Yes I can. This feature is, for me and many other users, a plain requirement. > after feature complete This has *already been in the product*. It arrived there before any feature freezes (although to my knowledge we have not yet reached a feature freeze). > after UI freeze Again. This was landed before any UI freeze. And I am still not aware of any UI freeze being in place. > with no design It was designed by the lead engineer on this feature and the relevant UI designer for the product. > or review It had both review and super-review. > just because you can identify a handful of people in a bug who claim > they need it. The people in question are not "in a bug". They are end users. They don't "claim" to need it. They are stating it as a requirement to use the feature. Just because you claim not to need it does not mean other users have the same usage patterns. > Adding features in such a manner What is the manner to which you refer? Do you mean adding features after they were inappropriately removed? Do you mean adding features with UE approval? Adding features that empower the user to make their computer do what they want? > is the hallmark of out of control bloatware. Like adding features such as an alert for "Save As" to tell the user what he just did? Or features such as tip of the day? How do we tell what is out of control bloatware and what is a good feature? I contend that this is an important, useful, even critical feature for many users. > This is not about what I personally want Strange, then, that you are arguing a position that is not held by either the lead engineer of the feature nor the UE designer at the time. If it was not what you personally wanted, wouldn't you hold the view point of those two people? > This is about what we need in the browser, Download managers are typically considered separate applications by users. In our world it is a "Tool", like the Document Inspector. It is not the browser. > and right now we need bugfixes, not more pref panels. This is a bug. And if we need bugfixes, not enhancements, why have you personally nsbeta1+ed bugs like bug 114476?

I'm not going to start quoting you quoting me in a bug. If you want to discuss this, take it to n.p.m.ui or n.p.m.browser, where it should have been brought up months ago.

Trudella, so you think that suddenly switching over to the download manager by default, and not letting the user have a choice about it fits better into "feature freeze"? Remember that the download manager has not had extensive testing (especially not the outliner-based one that is in now), and downloading files is a rather important part of the browser...

The download manager has been designed and planned since last July; the switch to outliner for about as long. They may not have gotten alot of testing yet, but they aren't unplanned additions. We don't automatically leave old behavior in as a 'choice', since it typically complicates and bloats the product to do so, and only a tiny number of extremely advanced users ever sees the alternates. If this was so obviously a critical need, why was it not added to the design spec or discussed in the newsgroups? Why are these prefs not in the competing browser that is used by many times the userbase? I contend that it is because they are not core, but frills that appeal to <1% of users, and we have too much higher priority work to do to spend valuable resources in this way. Unless someone has hard data that this adversely affects typical target users in a major way, it should be proposed and discussed for addition in a subsequent release.

I'm not going to argue over putting the pref in for Mozilla 1.0, but I think we should be able to test the d/l manager as default downloader in the nightly builds and the upcoming RC releases. That way we can stomp some bugs out of the d/l manager. I know I'm probably going to be ignored, but I do think we should get some more heavy testing into the manager...and by doing what I'm saying will help that cause.

*** Bug 132791 has been marked as a duplicate of this bug. ***

I applied patch v2 on top of current CVS, and it works perfectly. The tree options on the panel does that they're supposed to do, they are remembered on shutdown of mozilla and the panel looks right in both classic and modern. The Download Manager also launches by default now, and that option is correctly checked on the panel on first launch.

adding self to cc list

What platform did you test on? We need people to test it on Mac, Windows and Linux. I've tested Linux.

I tested it on Linux too, which is the only platform I have access to.

1.0 is getting closer and closer, and the Download Manager is still not showing by default. Just how untested do we want it in 1.0? Should I open a separate bug about that?

We don't necessarily want it showing up by default - do we? We just want to re-enable the pref panel so that we can choose to have it show up if we wish. Even if this were made the default choice, I'm sure that many would turn it off again via prefs.

Jason, the nice folks at Netscape have said that they want to make the Download Manager the default. Just read Trudell's comments in this bug.

I'm just saying that that's not what THIS bug is about. This bug is about making the pref panel visible.

I am satisfied with the current default, but that doesn't matter any more than anyone else's opinion. I don't know how the behavior has since changed to not show the DL Mgr by default, and am unaware of any bug filed to change it back. It does seem like we have created a new feature, only to hide it.

We just need people to test this on Windows and Mac... (I'm not using Tinderbox as my compiler, especially as this has Makefile changes.)

I'd would test this on windows for ya, I didn't have a problem with the first patch on 3/20 build with windows 2000, but I don't build mozilla either.. so having it on trunk would help us so we may test it.

renominating since bug 137440 was fixed (on the trunk).

The pref panel for the download manager needs to be enabled. As far as Moz goes, it doesn't really matter what options are enabled by default, because obviously features need to be tested. It DOES matter that the options are in fact available (aka visible) for something that is so noticeable in day to day usage. This is going into the "pet peeves" file under "argh!!!" If I want to see the download manager, I'll open it, thanks.

also see bug 141278, which seems like a dup of this one.

*** Bug 141278 has been marked as a duplicate of this bug. ***

Added myself to CC, with added comment: WTF is with this )!*@#)( download manager?!? I don't want my downloads managed/tracked, I want them DOWNLOADED. Sorry, I grew up on Netscape 1.22 on up. Is there a "Disable DL Manager" option in the UI Prefs publically (not in the prefs.js)? Let's at least make sure that's there.

*** Bug 143144 has been marked as a duplicate of this bug. ***

*** Bug 143122 has been marked as a duplicate of this bug. ***

I want to have an option to enable/disable this download manager. Just installed build 2002051608 and was surprised of this new function. It's good but not stable IMO and needs an option to turn off!

Mathias, Inserting the following into your prefs.js restores the former behavior: user_pref("browser.downloadmanager.behavior", 1); Posted this to the bug because the value seems to have changed from 2 to 1 recently.

Re: comment #46 I agree there should be a way to limit the size of downloads.rdf like there is for history. If it were a "number of days" type option, "0" could turn off the download history completely. I don't like the idea of having to manually clear my download history periodically. A feature intended to make downloading more convenient actually makes it much less convenient (in its present form.)

Kevin: I inserted: user_pref("browser.downloadmanager.behavior", 1); into my prefs.js and the Download Manager still pops up when I download files. I HATE this piece of ****, I don't want it, I can't stand it, I'm using IE to avoid it, this is rediculous. Ian: Isn't obvious yet that A LOT of people DO NOT WANT ANYTHING TO WITH DOWNLOAD MANAGER AT ALL. If I wanted one I'd download a 3rd party Download Manager, I don't care if it's included in Mozilla (and you don't care if I care), but you can't just expect everyone wants it. I hate the UI, I want the old download progress dialog WITH NO DOWNLOAD MANAGER, NONE AT ALL. If this cannot be accomplished let me know now, and I'll switch to a browser with less annoying 'features nobody wants.'

The problem is that the hidden pref doesnt keep the downloads from getting tracked and stored in the downloadmanager. It seems there are a lot of people who just dont want the downloadmanager. For these it would be good to be able to just switch it *completely* off.

RE comment #53: I have opened bug 146059 to address the retention of download history.

I got that pref to turn off the UI to work, dunno why my build wasn't taking it, downloaded todays 2002052108 build for win32 and it took the pref, wierd behaviour on my build since I hadn't even made changes yet. Something too look at.

Stan: the patch I attached allows you to completely disable the download manager.

Comment on attachment 82437 [details] [diff] [review] Patch: Version 3 sr=blake

nsbeta1+/ADT2 per Nav triage team.

Is this patch on the trunk?

*** Bug 146912 has been marked as a duplicate of this bug. ***

I think mpt prefers the phrase "progress window", and is the meaning of progress window clear? Would "individual progress window" or some such, be clearer, or would icons help?

"individual progress window" sounds good to me.

The inconsistency of the download manager must be resolved before 1.0 final. Having two download systems with no way to set their preferences is extremely confusing and a sign of lack of polish. Inconsistencies like this should be treated as critical bugs. I must say, as I read the debate on this bug I am at a loss, as it seems one camp has tested it and approves it, and one camp is against it. I don't know who makes the final call - I'm much more of a user of Mozilla than a developer - but it must be resolved. My personal preference would be to have it included with preferences to control which system is used (with the original system as a default). Every browser I've used on non-Windows systems has a form of a download manager, and I've always been amazed that Windows never did. However, if enough testing truly has not occurred then remove all traces in the final release and stick with the individual windows - it can be added later.

There is no "against" camp anymore as far as I can tell; the issue is merely one of getting the patch fixed and checked in. I don't have the time to do that for 1.0, sorry. Feel free to jump in and help.

*** Bug 147206 has been marked as a duplicate of this bug. ***

-> me

Comment on attachment 82437 [details] [diff] [review] Patch: Version 3 recording ben's r=

Comment on attachment 82437 [details] [diff] [review] Patch: Version 3 please check into the 1.0.1 branch ASAP. once landed remove the mozilla1.0.1+ keyword and add the fixed1.0.1 keyword

Needs adt approval as well. Marking adt1.0.1.

what about trunk? This has r= and sr=, so only someone needs to check it in - who will do that?

checked in to the trunk

When you change to d/l manager to default shouldn't the properties dialog have a close button (so you can gracefully close the menu without ending you d/l)? Do I need to make a bug report for that?

Yes please.

l10n approved if you get this checked into the branch by tomorrow. thanks

adding adt1.0.1+ for adt approval. Please check this into the branch today.

*** Bug 137441 has been marked as a duplicate of this bug. ***

tried checking into the branch but had to back myself out because the tree was closed. will try again later.

Fixed on the branch. Adding fixed1.0.1 and removing mozilla1.0.1+, which I believe is the magic encantation currently required to signal that the check in has been completed successfully.

vrfy'd fixed on both the trunk and branch, using 2002.06.10 comm builds on linux rh7.2, win2k and mac 10.1.5.