Closed Bug 132456 Opened 22 years ago Closed 15 years ago

download manager shouldn't automatically open when files are opened with a helper app (wait a few seconds?)

Categories

(SeaMonkey :: Download & File Handling, defect)

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

Tracking

(Not tracked)

Status:
RESOLVED WONTFIX

People

(Reporter: bugzilla, Unassigned)

References

Details

saw this while playing with blake's test build last week, but not sure if it's
on his list, or how feasible it'd be to fix... anyhow, currently testing with
2002.03.20 comm verification bits (thanks to akkana for reminding me).

basically, the download manager will automatically launch (when using the
default setting of "open the dl mgr" from the Downloads pref panel) even for
files that are being opened by a helper application (whether OS-defined or set
by the user).

is there some way to avoid displaying the dl mgr window in this case?

another follow-up question to that would be, is there some way the dl mgr could
avoid tracking files that are opened with an app rather than being saved?
Keywords: nsbeta1
Have to say that it's extremely annoying to get this big window with no "don't
show me this" option every time I click on a sound file.
afaict, IE (at least v 5.1 on Mac OS X) does what i'd expect: if a helper app
opens the file, the download manager window doesn't appear. moreover, IE's dl
mgr doesn't track (list) the files that had been opened by external apps.
Making download manager not track files opened by helper apps (and not open when
you choose "open with application") would be simple.
The download still occurs on Mozilla's watch, it's just sent to the helper app
once it has been downloaded. Why don't we want to track it? Imagine if you
download a 500MB ZIP file and told it to open with WinZip. How do you cancel it?
Nav triage team needs info: how do I reproduce this?  When I open MP3s with
WinAmp as the helper app (default config), I get a separate progress dialog, not
the DL mgr.
Whiteboard: [need info]
qawanted: Sairuh, can you reproduce this?
Keywords: qawanted
adding self to cc list
can no longer repro this using 2002.04.04 comm verif bits --mainly since the
default has been changed back to not automatically bring up the download manager.

should this be left open (if prefs UI are implemented, see 132440), or should it
be marked wfm? if left open, i suggest nsbeta1-.
Keywords: qawanted
Whiteboard: [need info]
I say close this.  But we should add a link to this bug (at least a comment) to
the bug tracking the issue of getting the preference and changing the behavior.

If that feature doesn't support this one, then we can reopen this bug or open
another one.
nsbeta1- per Nav triage team (and Sairuh ;-)
Keywords: nsbeta1 → nsbeta1-
Target Milestone: --- → mozilla1.1alpha
hmm, now there's bug 137440, where the download mgr would be opened by
default... will this bug crop up again when that's implemented?
Depends on: 137440
renominating, since bug 137440 was checked in (albeit on the trunk).
Keywords: nsbeta1- → nsbeta1
This is back, since the download manager is now on by default.  Furthermore,
there is no user-visible option to turn the damn thing off (bug 141278).  For a
user who opens PDF files off the web a lot, this is a an incredible annoyance. 
I understand Ian's position in comment 4, and I would not mind a small progress
window that showed me the progress of viewing my PDF and then _closed_ when the
transfer was complete.  But the download manager is 600px by 400px, which is
ridiculously huge, and has no autoclose functionality.

Renominating for nsbeta1; this is a major usability regression.
Another thought is that perhaps the current pref should be split into _two_ prefs:

1)  What to use (dialog, download manager, neither) for saving.
2)  What to use (dialog, download manager, neither) for tracking stuff that's
    going to get opened in a helper.

I'm not saying we _should_ do it, and I don't even know how reasonable it would
be to do... I personally would use that capability if we had it, but.... :)
Seems to me like this is a dup of the dlmrg pref bug, really. I don't see why a
download that will be saved to disk should be handled differently than a
download that will be opened in WinZip, especially considering 640MB files.

What we could do, though, is delay opening the dlmgr by a second or two if the
file is going to be opened in a helper app, that way small files will work
transparently. Or, we could just do what bz suggests and split the suggested
pref into two, one for saving and one for opening.
nsbeta1- per nav triage team.
Keywords: nsbeta1 → nsbeta1-
*** Bug 142768 has been marked as a duplicate of this bug. ***
This problem has recently cropped up again on Linux ix86 BuildID 2002052821.

A previous build (BuildID 2002052309) didn't have this problem: clicking on a
.pls file popped up a normal download progress dialog which quickly auto-closes.

The nightly snapshot 2002052821 pops up the download manager (and leaves it up),
which is *increadibly* annoying.

Either the download manager should not pop up for helper apps, or
it should only pop up if the download has taken more than (say) 2-3 seconds
and is still in progress.

Austin

*** Bug 148186 has been marked as a duplicate of this bug. ***
Do you want to surpress download dialogs as well?

What about on large files that need to download fully before being passed to the
helper...30 meg PDFs aren't uncommon....
(a) Current Mozilla 1.0 (BuildID 2002052918) doesn't show the download manager
        anymore, but uses a progress dialog instead.  So this bug is no longer
        so serious, but the root cause isn't fixed.

(b) Ideally, this progress dialog would only appear if the download has been
         in progress for (eg) 2 seconds and hasn't got past (eg) 80% completion.
Jeremy, the progress dialog has a major advantage over the download manager --
the "autoclose when done" option.  This option would be a little odd in the
download manager, unfortunately.  So no, disabling the progress dialogs makes no
sense since they don't get in the way once the data is there.
Summary: download manager shouldn't automatically open when files are opened with a helper app → download manager shouldn't automatically open when files are opened with a helper app (wait a few seconds?)
The download manager has started appearing (Build ID: 2002061104) even in the
mail client when an attachment is opened. This is fairly frustrating.
*** Bug 142978 has been marked as a duplicate of this bug. ***
*** Bug 168590 has been marked as a duplicate of this bug. ***
QA Contact: sairuh → petersen
I never saw this bug before (all versions up to 1.0.1),
but with Mozilla 1.2b I've found it.
W2K SP3, 2002101612
*** Bug 144262 has been marked as a duplicate of this bug. ***
retargeting
Target Milestone: mozilla1.1alpha → Future
Ben, you're working on this stuff, right?
Target Milestone: Future → ---
Blocks: 16498
taking.

Implementation plan:
In nsExternalAppHandler::CreateProgressListener:

Instead of always creating the nsIDownload object like this:
  nsCOMPtr<nsIDownload> dl = do_CreateInstance("@mozilla.org/download;1", &rv);
Create a progressdialog object if the download is to be opened in a helper app
(contractid: "@mozilla.org/progressdialog;1") and use that as the listener. just
remember to call Open on the dialog.

how does that sound?
Assignee: blake → cbiesinger
Sounds horrible. ;-)

See comment 15.
back to default owner.
Assignee: cbiesinger → download-manager
QA Contact: chrispetersen
Product: Browser → Seamonkey
Assignee: download-manager → nobody
QA Contact: download-manager
MASS-CHANGE:
This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state.

If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way.
If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar).
If no action happens within the next few months, we move this bug report to an EXPIRED state.

Query tag for this change: mass-UNCONFIRM-20090614
Status: NEW → UNCONFIRMED
What does Firefox do in this case nowadays?
Status: UNCONFIRMED → NEW
Firefox opens the Download Manager (DLM) if the preference is set. Firefox has a nice additional preference to close the DLM when all Downloads are finished.

As comment 4 stated, no difference between Target = Application or Target = File on Disk should be made. So Wontfix.
Status: NEW → RESOLVED
Closed: 15 years ago
Resolution: --- → WONTFIX
(In reply to comment #35)
> Firefox has
> a nice additional preference to close the DLM when all Downloads are finished.

There should be an open bug about this for our download manager, we just haven't gotten around to implement it yet.
I happen to think that comment 4 is nuts, but no longer care about this particular bug...
I have just voted for this bug (Saturday, 2010-01-02). It is *very* annoying to have to respond to the Download Manager, click the "Clear List" button, and close the Download Manager window, every time I pass a torrent file to uTorrent.

*Please* somebody fix this bug.

Thanx,

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