Closed Bug 141278 Opened 22 years ago Closed 22 years ago

UI for preference to disable download manager

Categories

(SeaMonkey :: Download & File Handling, defect)

x86
All
defect
Not set
normal

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
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
*** 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.
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.
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.
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
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).
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).
wouldn't this be the same as bug 132440?
#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?
OS: Linux → All
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...
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]
double-clicking an item in the dl mgr window doesn't appear to do anything, on any platform.
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).
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?
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.
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.
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...
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
*** Bug 142180 has been marked as a duplicate of this bug. ***
I find it annoying as all hell get out. Disable the thing *BY DEFAULT!*, and get a UI Prefs pannel for it.
*** Bug 142416 has been marked as a duplicate of this bug. ***
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.
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
> Marking as dup of 134220. I disagree with that assessment. I presume that you actually meant bug 132440.
Status: RESOLVED → REOPENED
Resolution: DUPLICATE → ---
*** This bug has been marked as a duplicate of 132440 ***
Status: REOPENED → RESOLVED
Closed: 22 years ago22 years ago
Resolution: --- → DUPLICATE
Er. Right. My bad. VERIFIED DUPLICATE
Status: RESOLVED → VERIFIED
Product: Browser → Seamonkey
You need to log in before you can comment on or make changes to this bug.