Closed Bug 132440 Opened 22 years ago Closed 22 years ago

Download Manager pref panel no longer visible

Categories

(SeaMonkey :: Download & File Handling, defect)

Product:
SeaMonkey
Component:
Download & File Handling
Type:
defect
Priority:
Not set
Severity:
major

Tracking

(Not tracked)

Status:
VERIFIED FIXED

People

(Reporter: ian, Assigned: bugzilla)

References

Details

(Keywords: regression, Whiteboard: [Hixie-P0][Hixie-1.0][ADT2 RTM])

Attachments

(2 files, 1 obsolete file)

Even the UI-competent competition have a pref panel for this
20.55 KB, image/png
Details
Patch: Version 3
10.96 KB, patch
bugzilla
: review+
bugzilla
: superreview+
jesup
: approval+
Details | Diff | Splinter Review 
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.
Keywords: mozilla1.0, regression
Whiteboard: [Hixie-P0][Hixie-1.0]
This is not implemented yet, actually..

Over to default owner.
Assignee: law → blaker
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?
Keywords: nsbeta1
OS: Linux → All
Hardware: PC → All
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
Keywords: nsbeta1 → nsbeta1-
Target Milestone: --- → mozilla1.2alpha
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
Assignee: blaker → nobody
Target Milestone: mozilla1.2alpha → ---
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.
Attached patch Patch: Version 2 (obsolete) — — Splinter Review 

    
    

    
  
*** 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.
Assignee: nobody → ian

    
    

    
  
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.
Depends on: 137440

    
    

    
  
renominating since bug 137440 was fixed (on the trunk).
Keywords: nsbeta1- → nsbeta1

    
    

    
  
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.

    
    

    
  

      
      
      
      

        Attached patch
          
          
        Patch: Version 3
        — 
          — Splinter Review
      

    


  

        Attachment #77181 -
        Attachment is obsolete: true

    
    

    
  
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

        Attachment #82437 -
        Flags: superreview+

    
    

    
  
nsbeta1+/ADT2 per Nav triage team.
Keywords: nsbeta1 → nsbeta1+
Whiteboard: [Hixie-P0][Hixie-1.0] → [Hixie-P0][Hixie-1.0][ADT2]

    
    

    
  
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
Assignee: ian → blaker

    
    

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

recording ben's r=

        Attachment #82437 -
        Flags: review+

    
  
Keywords: mozilla1.0 → mozilla1.0.1

    
    

    
  
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

        Attachment #82437 -
        Flags: approval+

    
  
Keywords: adt1.0.1
Whiteboard: [Hixie-P0][Hixie-1.0][ADT2] → [Hixie-P0][Hixie-1.0][ADT2 RTM]

    
    

    
  
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?

    
  
Blocks: 143047

    
    

    
  
checked in to the trunk
Status: NEW → RESOLVED
Closed: 22 years ago
Resolution: --- → FIXED

    
    

    
  
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.
Keywords: adt1.0.1 → adt1.0.1+

    
    

    
  
*** 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.
Keywords: mozilla1.0.1+ → fixed1.0.1

    
    

    
  
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.
Status: RESOLVED → VERIFIED
Product: Browser → Seamonkey

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






  

    
  







  

    

      
Attachment

      

      
      
      
      
    

    

      

        

          

            
General

            

              Creator: 



            

            
Created: 

            
Updated: 

            
Size: