Closed
Bug 141278
Opened 22 years ago
Closed 22 years ago
UI for preference to disable download manager
Categories
(SeaMonkey :: Download & File Handling, defect)
Tracking
(Not tracked)
VERIFIED
DUPLICATE
of bug 132440
People
(Reporter: Biesinger, Assigned: bugzilla)
References
Details
(Whiteboard: trunk only [need info])
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.0+) Gecko/20020405
BuildID: 2002042914
Currently, download manager appears for all downloads. this is pretty annoying.
Reproducible: Always
Steps to Reproduce:
1. right click an image
2. choose "Save Image"
3. click OK
Actual Results: Download manager appears
Expected Results: download manager should only appear if I want it, ie. there
should be a preference
Comment 1•22 years ago
|
||
This is absolutely necessary in light of bug 132456.....
biesi, the pref exists. See bug Bug 121324, comment 9. All that's needed is UI.
Keywords: nsbeta1
Summary: Preference to disable download manager → UI for preference to disable download manager
Comment 2•22 years ago
|
||
*** Bug 141321 has been marked as a duplicate of this bug. ***
Well I did not think anyone else found it as annoying as I do. And to see it
as a duplicate bug is hilarious. I was looking for a way to disable it and
there is not one. I sure hope they get rid of it.
Comment 4•22 years ago
|
||
Let's keep this bug focussed on the undesired behavior, rather than on the
proposed fix. It may be possible to improve this for MachV by, e.g. by changing
the behavior of the window to not become the active window, or not using DM for
saving, or other measures. Let's get the exact problem clear, and then come up
with possible solutions.
Comment 5•22 years ago
|
||
I don't see the download manager automatically using Mozilla RC1 under Linux or
WinXP.
The best thing would be to totally disable this feature, or keep it hidden
away in the Tools menu when people want to access it. Keep the downloader
which is currently used in the official RC1. This one automatically
dissapears, given the choice.
Comment 7•22 years ago
|
||
adding status whiteboard notation to make it clear what's up (and why I did not
bother to nominate this for 1.0 -- it's not relevant to 1.0)
Whiteboard: trunk only
Assignee | ||
Comment 8•22 years ago
|
||
Yes, it is easy to make the window not focus automatically if it's already open.
As far as I can tell, people's main concern seems to be that there's no way to
get the manager to close automatically, though (as was possible with the
progress dialog).
Comment 9•22 years ago
|
||
In my mind, the four main problems with the download manager as currently
implemented are:
1) It has no option to close automatically.
2) It takes focus when a new download starts.
3) It's very large.
4) It comes up when I'm not downloading anything (this is bug 132456).
#1 and #2 are pretty-much self-explanatory (making it not take focus would be a
nice improvement, since then a user could just keep it minimized). #4 has a bug
all to itself. #3 may need a little explanation:
The download manager's default size is 600px wide by 400px tall. This is
incredibly large on 640x480 or 800x600 displays -- it takes up almost the wholes
screen. It's about 1.5 times the size of the progress dialog we used before
this became the default, and we had bugs on _that_ being far to big to be
comfortably usable... Now I have a high-res display, so this does not bother me
very much personally, but I feel we should carefully evaluate this in light of
our target audience and above all test what users' reactions are to a window
suddenly popping up and taking up most of their screen.
It may be worthwhile to see whether the default size can be decreased without it
becoming ridiculous on high-res displays...
I don't know whether we want to file separate bugs on these issues or to keep
all the discussion/code/whatever in this bug (that's Blake's call anyway).
Comment 10•22 years ago
|
||
wouldn't this be the same as bug 132440?
Comment 11•22 years ago
|
||
#2 and #3 should be trivial to change, and the window already has the usual
sticky prefs for position and size. I'm not sure about such a window closing
auto-magically, can anyone point to examples of this working smoothly elsewhere?
Updated•22 years ago
|
OS: Linux → All
Comment 12•22 years ago
|
||
The current download dialog closes automagically (if the user so chooses) and
this works pretty well. Granted it "looks" like a dialog, not a window.
I assume double-clicking an entry in the download manager "launches" it on
Windows? If not, this would be yet another problem that should be fixed for
feature parity with the dialog...
Comment 13•22 years ago
|
||
Nav triage team needs info: would leaving the open window in the background be
appropriate, and would that and resizing be sufficient for now?
Whiteboard: trunk only → trunk only [need info]
Comment 14•22 years ago
|
||
double-clicking an item in the dl mgr window doesn't appear to do anything, on
any platform.
Comment 15•22 years ago
|
||
I strongly feel that making the window be able to auto-close is very important
for it to be usable, especially for people on broadband connections... With the
exception of Mozilla builds, every file I have downloaded in the last two days
has finished downloading _before_ the download manager opened (the
predownloading behavior we have makes it nearly impossible for me to choose a
filename before the file is done downloading). It's pretty useless to keep
having windows opening that tell you that your PDF has opened in Acrobat Reader
(I already know that, since the Acrobat Reader window is in front of me). Since
bug 132456 has been minused, that unfortunate situation will be quite common for
anyone using a DSL or cable modem connection.
Leaving the download manager open and not focusing it is a kludge that could be
used to work around that problem, but it's an incredibly annoying kludge (have
to keep remembering not to close the download manager).
Comment 16•22 years ago
|
||
I'm familiar with auto-closing progress windows, but I'm still not able to
visualize how this would work for a window with more functionality. Can you
point out another browser whose DL mgr works more like the way you want?
Comment 17•22 years ago
|
||
Well.. my point is that this window does _not_ have more functionality in most
cases. The only times it has more functionality are when you're downloading
multiple things at once or when you want to refer to what you have already
downloaded. These times are much rarer, in my experience, than just downloading
a file every so often.
Since you cannot "launch" the newly downloaded file from the download manager,
it in fact has reduced functionality in many cases....
In other words, I feel that it's over-engineered, for purposes of being the
default "progress window" thing. I agree that having a window that looks like
that auto-close would look a little odd (this is why I would prefer a pref to
use the old progress dialog to forcing this weird behavior on the download manager).
As for which browser has the behavior I find ideal.... I would say that is
Netscape 4 for Unix. When I'm saving a file it has a single 600px wide by 140px
tall window that lists source, destination, size, percent complete, speed, time
remaining, and has a "Stop" button to cancel the download (screenshot provided
on request). When I'm opening a file in a helper app, the progressmeter of the
browser window in which I clicked the link to the file is used to indicate
progress; no dialog appears at all.
Comment 18•22 years ago
|
||
Well, that is more than you can do with a single progress dialog. It also gives
a record of downloads, and shows them in the platform file manager. The
inability to launch should be a separate bug report. But, what about users who
explicitly open and use the DL manager, would they need to continually reopen it
because it auto-closes? IMO, windows that are explicitly opened by the user
should stay open until explicitly closed. Having a secondary/utility window
close by itself seems weird, so I'll ask a third time if anyone can point to any
app doing this.
In any case, there will be small window for those UI tweaks that prove necessary
to land before RTM, so if this gets into the trunk we could consider it for the
branch later.
BTW, using the windows progress meter was a defect in 4.x, or at least not a
general solution, because that may be needed for the page, and it cannot scale
to even 2 such downloads.
Comment 19•22 years ago
|
||
I agree that having the download manager autoclose would be very odd. I've been
focusing on the undesired behavior (window keeps appearing or even just hangs
around that I absolutely do not want), as requested in comment 4. The other
issues I have mentioned should certainly be fixed, but the autoclosing is the
one real issue for which I see a need for the preference this bug requests to
start with...
Comment 20•22 years ago
|
||
I have to add my complaints about this "feature" - I understand that the
Download Manager was made a default in order to better test it; I've never used
it (since I hate D/L managers in general), so the fact that the UI has not
changed in 6 months in completely meaningless to me. However, now that I am
forced to see the thing, there are a number of things that I [violently] object to:
[First off, I am running Win2K, which will account for some of the defaults. I
am also in a corporate IT department, so I see serious support issues as well.]
1) I don't want to see the history of everything I ever downloaded. I cannot
think of a single time when this would be useful to me personally, and I can
think of lots of times when having this on for all users will just increase the
number of calls I get like "I went to download a file and it showed me this page
with all sorts of files on it...."
2) I refuse to allow M$loth (and Mozilla by extension) to decide where my files
get downloaded to; I store my downloads initially in C:\Downloads until I decide
whether to keep it (and move it elsewhere) or delete it. I *hate* the idiotic
deep path that M$loth decided should be the normal destination for some
downloads. This is also a major support issue "I downloaded a file and now I
can't find it" with end users. I am mystified as to why Mozilla sometimes asks
where to store the file and other times is just dumps it into a uselessly deep
folder (it may be a HTTP vs FTP transfer thing). I want to be asked every time,
or at least have the option to force that...
3) I am on a full T1, so any file < 1MB is downloaded long before the Download
Manager comes up, thus negating any functionality it might have had. Then the
stupid thing just sits there, taking up screen space. Why can't you have it
vanish at the end of download iff it was not called via Tools/Download Manager?
This will also needlessly confuse end users.
4) I need a way to turn this stupid thing off. I don't care if 99% of the
people leave it on and think it is the best thing since the mouse, I HATE IT.
It doesn't help me in any way. I'm sorry someone spent a lot of time specing it
out and trying to make it useful; I don't like it and I won't use it and I have
to have a way to turn it off. Forcing users to use a feature is way to M$loth
for me...
Thanks
Comment 21•22 years ago
|
||
*** Bug 142180 has been marked as a duplicate of this bug. ***
Comment 22•22 years ago
|
||
I find it annoying as all hell get out. Disable the thing *BY DEFAULT!*, and
get a UI Prefs pannel for it.
Comment 23•22 years ago
|
||
*** Bug 142416 has been marked as a duplicate of this bug. ***
Comment 24•22 years ago
|
||
The download manager in build 2002050504 for WinME is filled with seemingly
random files from my disk and crashes when I try to remove those.. I'd like the
old dialog back till this gets fixed.
Comment 25•22 years ago
|
||
Marking as dup of 134220. Please file separate bugs for:
* dlmgr takes focus when a new download starts
* dlmgr default size too large.
* dlmgr should not open if the download is already complete
*** This bug has been marked as a duplicate of 134220 ***
Status: NEW → RESOLVED
Closed: 22 years ago
Resolution: --- → DUPLICATE
Comment 26•22 years ago
|
||
> Marking as dup of 134220.
I disagree with that assessment. I presume that you actually meant bug 132440.
Status: RESOLVED → REOPENED
Resolution: DUPLICATE → ---
Comment 27•22 years ago
|
||
*** This bug has been marked as a duplicate of 132440 ***
Status: REOPENED → RESOLVED
Closed: 22 years ago → 22 years ago
Resolution: --- → DUPLICATE
Comment 29•22 years ago
|
||
Updated•20 years ago
|
Product: Browser → Seamonkey
You need to log in
before you can comment on or make changes to this bug.
Description
•