Closed Bug 58744 Opened 24 years ago Closed 3 years ago

3rd party download managers not supported

Categories

(Firefox :: File Handling, defect, P3)

Product:
Firefox
Component:
File Handling
Platform:
x86
All
Type:
defect

Tracking

()

Status:
RESOLVED INCOMPLETE

People

(Reporter: thenerdgod, Unassigned)

References

Details

Attachments

(1 file, 5 obsolete files)

complete patch
17.50 KB, patch
Details | Diff | Splinter Review 
From Bugzilla Helper:
User-Agent: Mozilla/4.76 [en] (Windows NT 5.0; U)
BuildID:    all

Since Netscape version 1.0, it has supported OLE automation.  A large number of 
other programs rely on this, including all Download Managers.  The lack of OLE 
means they can't take over downloads from the browser.

www.getright.com www.gozilla.com are a couple of the download managers.

Reproducible: Always
Steps to Reproduce:
1. use GetRight with Netscape.
2. Click any EXE file
3. GetRight is not able to take over

Actual Results:  Netscape did the download            

Expected Results:
--> xp apps

i see that too, getright fails with mozilla but works with ns4.7x.
Assignee: asa → don
Status: UNCONFIRMED → NEW
Component: Browser-General → XP Apps
Ever confirmed: true
QA Contact: doronr → sairuh
not familiar with this... pls punt back --or to the appropriate component-- if
ActiveX is the wrong one.
Assignee: don → locka
Component: XP Apps → ActiveX Wrapper
QA Contact: sairuh → cpratt
This is by design.
Status: NEW → RESOLVED
Closed: 24 years ago
Resolution: --- → INVALID
Marking verified.
Status: RESOLVED → VERIFIED
small question: why no OLE? Just wondering why.
Small pieces of OLE have been used on Win32 here and there to support drag and 
drop and Internet shortcuts. OLE in general is not supported because it is a 
non-trivial and platform specific task to write code to implement a 
security model for trusted/untrusted content, to download & unpack 
(proprietary) CAB files, verify signatures and then host ActiveX controls in a 
page. 

In this instance, I don't know what the reasons are for not supporting download 
managers. Does 4.x do it by OLE or is this a misunderstanding? It should be 
possible for the download manager to override which apps get invoked to handle 
mime types. Since this is a navigator issue (nothing to do with the ActiveX 
control), I'm punting this one back to XPApps for reconsideration.

As a workaround, you might find you can drag and drop the link from the Mozilla 
window onto your download manager. 

Searching through "Classic" Mozilla 5.0 (basically 4.x) might reveal how it 
used to be done:

http://lxr.mozilla.org/classic/
Status: VERIFIED → REOPENED
Component: ActiveX Wrapper → XP Apps
Resolution: INVALID → ---
Changing description, reassigning.
Assignee: locka → don
Status: REOPENED → NEW
QA Contact: cpratt → sairuh
Summary: OLE not supported. → 3rd party download managers not supported
4xp issue
Keywords: 4xp
don, who in your group should own this?
Not sure if this helps at all, but these are the keys that GetRight (and I'm
assuming others too) use to do this in 4.x:

[HKEY_CURRENT_USER\Software\Netscape\Netscape Navigator\Automation Protocols]
"http"="GetRight.Automation"
"ftp"="GetRight.Automation"

Which is then a reference to this chunk (don't you just love regedit's formating ;)

[HKEY_CLASSES_ROOT\CLSID\{4DA2C32A-4195-11D1-A9E1-00403320FCF2}]
@="GetRight.Automation"
[HKEY_CLASSES_ROOT\CLSID\{4DA2C32A-4195-11D1-A9E1-00403320FCF2}\DefaultIcon]
@="C:\\PROGRA~1\\GETRIGHT\\GETRIGHT.EXE"
[HKEY_CLASSES_ROOT\CLSID\{4DA2C32A-4195-11D1-A9E1-00403320FCF2}\LocalServer32]
@="C:\\PROGRA~1\\GETRIGHT\\GETRIGHT.EXE"
[HKEY_CLASSES_ROOT\CLSID\{4DA2C32A-4195-11D1-A9E1-00403320FCF2}\ProgId]
@="GetRight.Automation"
[HKEY_CLASSES_ROOT\CLSID\{4DA2C32A-4195-11D1-A9E1-00403320FCF2}\MiscStatus]
@="32"
[HKEY_CLASSES_ROOT\CLSID\{4DA2C32A-4195-11D1-A9E1-00403320FCF2}\Insertable]
@=""
[HKEY_CLASSES_ROOT\CLSID\{4DA2C32A-4195-11D1-A9E1-00403320FCF2}\verb]
[HKEY_CLASSES_ROOT\CLSID\{4DA2C32A-4195-11D1-A9E1-00403320FCF2}\verb\1]
@="&Open,0,2"
[HKEY_CLASSES_ROOT\CLSID\{4DA2C32A-4195-11D1-A9E1-00403320FCF2}\verb\0]
@="&Edit,0,2"
[HKEY_CLASSES_ROOT\CLSID\{4DA2C32A-4195-11D1-A9E1-00403320FCF2}\InprocHandler32]
@="ole32.dll"

again, not sure if this helps, but this is something that I REALLY want, so just
decided to post whatever info I got.
From Josh Soref <soref@wam.umd.edu>:

You're missing a connection.
You can't get from "GetRight.Automation" to "{4DA2C32A-4195-11D1-A9E1-00403320FCF2}"

Well, he's right...here's the missing link (sorry bout that):

[HKEY_CLASSES_ROOT\GetRight.Automation]
@="GetRight.Automation"
[HKEY_CLASSES_ROOT\GetRight.Automation\protocol]
[HKEY_CLASSES_ROOT\GetRight.Automation\protocol\StdFileEditing]
[HKEY_CLASSES_ROOT\GetRight.Automation\protocol\StdFileEditing\server]
@="C:\\PROGRA~1\\GETRIGHT\\GETRIGHT.EXE"
[HKEY_CLASSES_ROOT\GetRight.Automation\protocol\StdFileEditing\verb]
[HKEY_CLASSES_ROOT\GetRight.Automation\protocol\StdFileEditing\verb\0]
@="&Edit"
[HKEY_CLASSES_ROOT\GetRight.Automation\Insertable]
@=""
[HKEY_CLASSES_ROOT\GetRight.Automation\CLSID]
@="{4DA2C32A-4195-11D1-A9E1-00403320FCF2}"
Since Don has left, Vishy is taking his bugs in bulk, pending reassignment.
thanks,
	Vishy
Assignee: don → vishy
nav triage team:

We should do this, marking nsbeta1, mozilla0.9.1, reassigning to law
Assignee: vishy → law
Keywords: nsbeta1
Target Milestone: --- → mozilla0.9.1
*** Bug 64757 has been marked as a duplicate of this bug. ***
This is an important feature since NC4.x and IE are both supported by GetRight
and these download managers have become VERY popular in the last 12 months.
Hardly any power-user is without a download manager these days. This could
become a hindrance to popular acceptance ("don't use Mozilla, it doesn't support
download managers").

Suggest to move to sooner milestone (mozilla 0.8 or mozilla 0.9). Thank You.
Target Milestone: mozilla0.9.1 → Future
Target Milestone: "Future"? ... rats :-|
It would be very nice if you will make an option like "Choose an external
download handler"

Now all the user should do is to choose the file "getright.exe"

Adding keyword to keep plario happy :)
Would be nice to have I guess but I always use download managers with clipboard
monitoring, so if I wanna download with getright I right click and select "copy
link location", for small files I just click on it and let mozilla handle it.
Keywords: mozilla0.9.1
The Mozilla Download Manager could have clipboard monitoring ;)

Also suggest the is is possible to close all Mozilla windows, but if a mozilla
download is in progress, the process is *NOT* terminated, but rather displayed
in the taskbar (next to clock) - very cool :)
Blocks: 75364
OK, I've been convinced that the average cat won't eat this food till this is
fixed :) Now if you use any download manager hassle the company that makes it to
help support moz by either implementing this themselves or list requirements
that need to be fulfilled for their download manager to work with moz.
Keywords: nsCatFood
The thing is with clipboard monitoring/click monitoring you should choose the
file types you download with GetRight...

With the "Choose an external download handler" option all the files types
Mozilla can't view will be downloaded automatically with GetRight (or any other
program).
From the author of GetRight:

While IE and earlier Netscapes used totally different methods, with each there 
was *some* way for an external program (DLL) to "preview" URLs before they were 
opened in the browser.  And the external program has some way to say "Yes, I'll 
Handle It" or "No, the Browser should handle it".

And even then the two were different.  If I've remembered them right, IE sends 
every URL that makes up part of the page, so every image, frame, etc; while 
Netscape only sends ones the user actually clicks on (so just the page itself 
without any elements.)  

And they handled Location redirection differently too.  IE just lets the 
program see the first URL, not sending any location redirects; while Netscape 
does let the external program see the location redirects for each step.

And neither handle too well if more than one program is trying to do the same 
thing.  So more than one download manager at the same time often does get 
conflicts with them overwriting each other's settings.

Plugins can sort-of do it (the Opera ones works now with NS6 
www.getright.com/opera.html ).  But some big quirks.  There's no way to 
say "NO" if the user doesn't want the download manager to take over.  And the 
list of types it can take over are built into the plugin DLL itself, so can't 
be dynamic or use SHIFT+click sorts of things to do simple exceptions.  Plus 
the plugin gets started, so shows a fullscreen plugin, which is a hassle to 
keep going Back if you're adding a bunch.

There may even be a way to do it in Mozilla, I didn't read all million lines of 
source, and didn't find any documentation about any ways that might do it :)  
It's a function few programmers would use (mostly us download manager 
authors).  But download managers are used by a Huge number of people.

All GetRight and the others would need is some way to have Mozilla call a DLL 
for each URL, with the URL as a parameter, and be able to return a TRUE or 
FALSE to say if it or the browser should do it.  If there's a way to do that 
that I haven't found, or it can be added, a simple patch for GetRight to add it 
could be done in days.

-Michael Burford
I think Communicator did this via DDE.  There's issues with that (see bug
71720).  This is hard and not a top priority.  Minusing.
Keywords: nsbeta1 → nsbeta1-
A generic documented way to do this is the most desirable course, but it is 
possible for 3rd party apps to listen to clicks right now with some work. A 
couple of ideas spring to mind:

Write and install a chrome overlay that listens for mouse click events and 
runs some small exe with the clicked URL as a parameter. This exe would locate 
or launch the download manager which would take it from there. Chrome overlays 
would also allow tighter UI integration between the download manager and 
Mozilla, such as new menu items, dialogs etc.

Another alternative would be to write a replacement for the unknown content 
handler or the stream transfer objects which do the save to disk operations in 
Mozilla. Register your own object with the correct component category and it 
should be invoked whenever Mozilla wants to save something.

Check that; it's bug 71270 that scares me off broadcasting the URLs to external 
applications.
Bah. Hush.

We already have a way to let components register as content handlers
(nsIContentHandler), though I don't think we have an elegant way to give one
handler priority over another (correct me if I'm wrong).

In other words, we don't need to broadcast, all the download manager has to do
is install a mozilla component which registers and says "Okay, I'll take that"
or "Nah, let someone else deal with this".
nav triage: not a catfood issue.
Keywords: nsCatFood → nsCatFood-
One suggestion on how to do it securely...

When installing a downloader, it should add itself into Mozilla's "install
this"-list. When Mozilla is next started, it should check out that list and ask
e user if the downloader should be used.

The download should be passed to the downloader should be when either
-Mozilla can't internally (or with plugins installed) display the file AND user
does a simple click.
-User does Alt-Click (or some other combination).

In my opinion there is no need to return anything to Mozilla from the downloader.
Blocks: advocacybugs
No longer blocks: advocacybugs
Blocks: advocacybugs
spam: over to File Handling.
Component: XP Apps → File Handling
Adding mjb@getright.com to CC list. 

MJB, if you mind, please let me know and I'll remove you from the CC list ASAP.
I'm hoping though, you can use the input provided after your (brief) appearance
here, and hopefully get GetRight to work with Mozilla. ;)
I've looked at several of the methods posted here, but (obviously) haven't 
gotten anything to work.

Some help with code from a Mozilla/Netscape expert would be greatly appreciated-
-could probably even pay a bit if that helps get it done quicker (as we're 
approaching the 1-year anniversary of this bug :-)

-Michael Burford
OS: Windows NT → All
*** Bug 118037 has been marked as a duplicate of this bug. ***
Nominating for Mozilla 1.0. (Bill:I know that you have too many bugs  :-( )
We have a getright developer who wants to help (comment #31).
Keywords: mozilla1.0
mjb, I just ran across getright's latest mozilla version of the plugin.. I
didn't even close the browser and it worked after I installed it and getright
itself.  

I didn't pay attention to anything I didn't but I went to save some file and it
popped up getright and it saved the file. :)
> I just ran across getright's latest mozilla version of the plugin..

Where exactly can we run across the plugin to test it?
who knows, but http://www.getright.com/addons.html lists it, so my guess is 
that you just get a current plugin.
OK, I found the plugin. It is available from the (misnamed) URL
http://www.getright.com/opera.html

It worked for me for .exe and .zip files (mozilla0.9.8 for Win32).
I have been using it since 0.9.7+. Works fine for me with straight links to
compressed files or binaries. 

It does gets confused when the link is via a form POST, not sure if it is the
POST hiding the file type, or the server Header not identifying the mime type fully.
Keyword on Platform says 'PC'- I'm afraid that you can probably find download
managers for just about any platform, very few of which work well with Moz.
Galeon seems to do this rather well- anybody checked what they do?
Getright's latest mozilla version of the plugin deosn´t work with e-mail
attachments. When the plugin is active the Mozilla browser downloads are working
well but when I want to access to an e-mail attachment like a zip- or ppt-file
getright tries to download the e-mail attachment. After de-installing the
Getright browser plugin I can access to the e-mail attachment withot any problem.

I work with Mozilla 0.9.9 (Engl + Deutsch (from Austria)) (Mozilla/5.0 (Windows;
U; Win98; de-AT; rv:0.9.9) Gecko/20020311) and Mozilla 0.9.8.
*** Bug 129780 has been marked as a duplicate of this bug. ***
At 2002-03-16 I asked Mr. Burford from Getright to solve the problem with the
downloaded mail attachments (look at my message to this bug).
 
Now something had changed:  With the new versions of Mozilla (1.0rc1) and
Getright 4.5d the Getright-Mozilla-plugin will no longer try to download the
attachments: now there comes up an error. - But an error means that Mozilla and
Getright do not work together in a right way. Because of this I was going on to
ask Mr. Burford. Here is my mail and his answer:

Rainer Schnell wrote:
> 
> Hallo Mr. Burford,
> 
> now I try to work with your plugin with new versions of Software. I use
> getright 4.5d and Mozilla 1.0rc1 (Mozilla/5.0 (Windows; U; Win98; de-AT;
> rv:1.0rc1) Gecko/20020417).
> 
> The new verification in your e-mail attachment handling is that getright
> does not want to download the attachments any longer. It only shows an
> error with the file address getright reaches (look at the picture I sent
> with this e-mail).
> 
> Now my question:
> 
> At the beginning of the file-address getright gets from Mozilla there is
> written "mailbox:///c|/". The expression "mailbox:" ist not similar to
> "ftp:" or "http".
> 
> Can't You tell Mozilla after checking the beginning of the fileaddress
> that getright will not run any download and Mozilla should start instead
> of this the programs to which the file types belong to?
> 
> Greetings from Germany
> 
> Rainer Schnell


Mr. Burford answered:

Yeah.  The real problem is that years ago when someone designed the
Plugins, they didn't leave any way for a plugin to say NO.  (Or I
haven't found any way.)

The plugin can easily check the URL to see if it's a type it should
handle, but there is no way for it to tell Mozilla it can't do
it...Mozilla just expects it to handle the file.

-M

the e-mail-adress of Mr. Burford is 

mjb@getright.com   (Michael Burford (GetRight))

I hope that someone of the Mozilla developers will write to Mr. Burford to solve
this problem.
*** Bug 143117 has been marked as a duplicate of this bug. ***
Blocks: 164421
QA Contact: sairuh → petersen
Flags: wanted1.3a?
Keywords: mozilla1.0
Flags: wanted1.3a? → wanted1.3a+
Flags: wanted1.3a+ → wanted1.3a?
We're not going to hold 1.3a for this. (The "wanted1.3a" flag has been changed
to "blocking1.3a" to more accurately reflect how the flag is used by
drivers@mozilla.org).
Flags: blocking1.3a? → blocking1.3a-
On Mac OS X we've got iGetter.
It installs a plug-in that integrates with the browser in two ways:
1) captures and transferes links that it has been told to intercept
   this feature works rahter well - even for redirected URLs like the ones used at
   http://www.versiontracker.com. Only problem seems to be if the server doesn't
   return the correct mime-type
2) install two options in the context-menu
   this doesn't work in Mozilla, and works with varying success in the other
   browsers for Mac OS X

the relevant URLs discussing this seems to be:
http://www.igetter.net/forums/showthread.php3?threadid=257
http://www.igetter.net/forums/showthread.php3?threadid=334
http://www.igetter.net/forums/showthread.php3?threadid=319

*** Bug 204876 has been marked as a duplicate of this bug. ***
Mozilla should allow third party download managers.  I use DAP which supports
multiple download threads for each download as well as resume.  Both are very
helpful, especially for dialup connections.
"allow" is the wrong word. We need an interface or something like that to send a
download to the download manager (URL, referer, Auth Informations) but be sure
that the DM don't get the "internal downloads" (Attachment in a mail...) and
that Mozilla use it's own Download-functions if the DM doesn't respond in a
short time (timeout)

 
And the download manager should be able to actively deny the download, for
example if the requested protocol isn't supported (download manager not able to
use https: for example). In this case Mozilla should download on his own.
*** Bug 208632 has been marked as a duplicate of this bug. ***
taking... I'm not 100% sure how to implement this yet, it may depend on the fix
for bug 58554, marking dependency for now

(I'll make this compatible with the NS 4.x way, unless people have objections to
that)
Depends on: 58554
oops, really taking
Assignee: law → cbiesinger
Target Milestone: Future → mozilla1.6alpha
Attached file code to talk to getright (obsolete) — 
this is example code for talking to getright (ask if it wants to handle the
download, and tell it to handle it). should work for anything that registered
for NS4, but it has Getright's progid hardcoded.

(attaching for archival purposes)
clearing dependency. it's not needed to fix this.
No longer depends on: 58554
OK, if anyone cares, I found a very good way for implementing this
mjb: this makes the email I sent you wrong

I'll use nsIContentPolicy. still hoping to land a ns4x compatible way for doing
this in 1.6alpha; *maybe* in 1.5beta but that's unlikely, maybe an XPI for this
earlier than 1.6a.
Attached patch patch part 1 (obsolete) — — Splinter Review 
this includes the changes to existing files
Attached file "patch" part 2 (.tar.gz) (obsolete) — 
this .tar.gz contains the new files. untar in xpfe/components.

I picked the name ns4hooks because I'm implementing an api also present in NS
4.x
Attachment #127756 - Attachment is obsolete: true
Status: NEW → ASSIGNED
You guys really need to get this problem resolved. More and more web pages
are getting "Netscape 4.7 Unfriendly", and I have to copy the URL to the
clipboard and go into Internet Explorer (blech!) to get GetRight to get
right :)

I'm ready and willing to be either a beta tester or even an alpha tester
for this problem.

Thanx,
Jim H. (aka CuriousJ)
I second to that - this really must be done now, and not just postponed another
year (hell, it's already almost three years old!). For me, this is the very
biggest flaw in Mozilla now.

Of course, an alternative to this would be making the internal download manager
VERY GOOD. This means no broken "finished ok" downloads, full resume in all
cases (even for starting a new download over existing local file), etc. I know
this isn't going to happen, so better just add the simple support for GetRight
(and the others too).
I disagree that improving the download manager is a solution. Mozilla runs
with so much overhead that it will never equal the speed at which GetRight
can download, even with segmented downloads.

With enough mirrors, I can download a file at 700+ Kps (*not* kilobits,
Kilobytes) with GetRight over my cable connection.

Sincerely,
Jim H. (aka CuriousJ)

Why do you start a uiseless discussion (this is no Forum)?
There is a patch and we wait only for the reviews.
(and a review needs time)

1. The "patch", part 1 looks like programmer's code to me ... not much good
without a compiler, so how can I review it? To me, a patch is an .exe file that
I run in the applications folder, that modifies the program or a .dll (or .ocx,
or whatever).

2. The "patch", part 2, ostensibly linking to .tar.gz file ... nothing happens
when I click the link. No download occurs.

it's a patch for the mozilla source code. This patch needs a review by other
developers and in this case by "jag" (see the attachment flag in the attachment
list). You must either attach it to your own Mozilla source tree or wait that
this patch gets review and will be checked into the mozilla tree. The next
nightly will conatin the fix after the checkin.


please don't add any more nontechnical comments  to this bug. What this needs is
a review by a person like jag.

As an intermediate solution, I might make an XPI available to support external
download managers.
Comment on attachment 128536 [details] [diff] [review]
patch part 1

this misses a change to allmakefiles.sh...
Attachment #128536 - Attachment is obsolete: true
Attachment #128536 - Flags: review?(jag)
Attachment #128537 - Attachment is obsolete: true
Attachment #128537 - Flags: review?(jag)
Attached file "patch" part 2 v2 (obsolete) — 
do a bit more error-checkin
Comment on attachment 135347 [details] [diff] [review]
patch part 1 v2

trying different reviewer.
neil, please also review the other attachment on this bug
Attachment #135347 - Flags: review?(neil.parkwaycc.co.uk)
Comment on attachment 135347 [details] [diff] [review]
patch part 1 v2

Looks like the right idea but trying someone who might actually understand COM
;-)
Attachment #135347 - Flags: review?(neil.parkwaycc.co.uk) → review?(BradleyJunk)
I know back in the Win95 days calling API functions like RegQueryValueEx with
null values to figure out the buffer length would cause access violations. I
know that Win95 is no longer supported, but does this defect still exist in
Win98 and WinME?
Re comment 70: RegQueryValueEx with null type and data pointers works for me on
Win98SE.
Attachment #135347 - Flags: superreview?(jst)
Would someone cvs add the new files and provide a diff with the new files in the
diff rather than providing them separately?
Attached patch complete patch — — Splinter Review 
(does not differ from v2, except merged to trunk)
Attachment #135347 - Attachment is obsolete: true
Attachment #135348 - Attachment is obsolete: true
Attachment #135347 - Flags: superreview?(jst)
Attachment #135347 - Flags: review?(BradleyJunk)
Attachment #141573 - Flags: superreview?(jst)
Attachment #141573 - Flags: review?(BradleyJunk)
Ok, i'm testing this patch with Firefox 0.8. My thanks for writing this patch
-- this is one of those features that i think mozilla desparately needs.

I've tried a number of download managers. Most work just fine. This includes:
GetRight
Reget
Star Downloader
Fresh Download

The one download manager that I did run into to trouble with was FlashGet. Here
is the nature of the problem:

1. I click on a download link from Firefox (let's say a zip file).
2. Flashget's download dialog is displayed, which i expect.
3. Firefox also begins downloading the file, which is unexpected.

I cannot reproduce this behavior with Netscape 4.08, which leads me to believe
there is something going on with the patch, and that this is not necessarily
a flashget thing.

I am using Firefox, so it's very possible that this has something to do with
the Firefox download manager. To verify whether this is a Firefox specific
problem, can someone download Flashget and test this patch with non-Firefox
Mozilla? What i'm interested in knowing is whether mozilla tries to download
the file even after flashget has intercepted it.

Here is where you can find Flashget:
http://www.amazesoft.com/download.htm
Isn't this discussion relevant to the proponents of the new, extended plugin
technology  announced on http://www.mozilla.org/press/mozilla-2004-06-30.html ?
As Michael Burford pointed out in comment #22, one  of the things that up to now
made using Mozilla together with GetRight or other third-party download managers
less than totally  satisfactory were  limitations on the plug-in model.
While I do applaud Christian Biesinger's efforts to restore the "old" Netscape
API  (although his patch, AFAIK, hasn't landed in the trunk yet), a cure for the
plug-in shortcomings would probably be more helpful in the long run -- it would
benefit Opera and Safari users, for one, and it probably would be helpful for
developers of other third-party products beyond download managers.

By the way, what is the relevant bug for the new plug-ins?
The new extended Plugin API doesn't help because it's only for scripting
support... (AFAIK).
Downlaodmanager integration with a plugin is more a hack and the plugin API is
not for this kind of things...

And there is already a great extension for external download-managers in
Mozilla, see http://downloadwith.mozdev.org. I don`t need more.
Well, I don't know enough about the subject. But  I do  think  that the new,
expanded plugin API should shouldn't be limited to help just  Macromedia, Sun
and Apple. Flash, Quicktime and Java are nice,  but they  aren't the only 
plugins out  there. As long as they are doing a more  powerful API for plugins,
other plugin vendors should offer their  input on what other features would help
them.

I don't know; maybe the scripting, as proposed, would be enough to make Michael
Burford and other purveyors of download managers very happy. Maybe not, and a
few  tweaks would help. What I DO know is that if they miss this opportunity to
voice their needs, the next one wouldn't come for some years.

By the way, I also use  DownloadWith. It´s very nice, I admit. But I still miss
the hot-key convenience available on NS4 and IE...
(In reply to comment #77)
>  As long as they are doing a more  powerful API for plugins,
> other plugin vendors should offer their  input on what other features would help
> them.

download managers and plugins are fundamentally different concepts.
Is there any chance of this making it into Mozilla by Firefox 1.0? Given that
bug 230870 is (understandably) being pushed off until a later release, this
seems like a reasonable stop-gap measure. Especially since biesi has a patch
awaiting review here.
Flags: blocking-aviary1.0?
Flags: blocking-aviary1.0? → blocking-aviary1.0-
Flags: blocking-aviary1.5?
Flags: blocking-aviary1.5? → blocking-aviary1.5-
Using "Download with" eats up System Resources ... Use it too many times and I have to reboot.

I have had to resort to having GetRight monitor the Clipboard, which works when the download is triggered by clicking on an actual link (Right-click link, select "Copy Link to Clipboard") but not when the download is started through some kind of java or javascript applet or by clicking on a "button" on the web page (presumeably also triggering a java or javascript applet).

Jim H. (aka CuriousJ)

Hmm, can you believe that I had forgotten I posted on this bug?
Anyway, things have changed since the last comment. DownloadWith has been languishing forgotten for the last four years, but FlashGot took its place with a vengeance: it supports a lot of external download managers and it's well-supported and frequently updated. Frankly, maybe it's time to either close this bug or to redefine it in terms of "incorporating FlashGot code into the trunk."
QA Contact: chrispetersen → file-handling
My Mozill FF 3.5.1 unfortunately, doesn't work with ReGet Deluxe download manager directly (from the browser). So I have to "copy & paste" links for downloads from browser to ReGet. I hate Internet Explorer, but I still keep it on my computer just because it CAN "reget" any link right from the browser. If Mozilla could do just the same, I'd be happy to uninstall this stupid IE completely! In fact I have a DownThemAll add-on istalled, but it's kinda weaker than ReGet, that's why I'm so upset!
My Mozilla FF 3.5.1 unfortunately, doesn't work with ReGet Deluxe download manager directly (from the browser). So I have to "copy & paste" links for downloads from browser to ReGet. I hate Internet Explorer, but I still keep it on my computer just because it CAN "reget" any link right from the browser. If Mozilla could do just the same, I'd be happy to uninstall this stupid IE completely! In fact I have a DownThemAll add-on istalled, but it's kinda weaker than ReGet, that's why I'm so upset!
This should only provide an entry point for a downloadmanager but it's not needed anymore with the addon system and things like flashgot.

biesi: would it be ok to mark this bug wontfix ?
Comment on attachment 141573 [details] [diff] [review]
complete patch

Clearing stale review request. If someone's actively still working on this, and we actually need this, please request reviews again.
Attachment #141573 - Flags: superreview?(jst)
Attachment #141573 - Flags: review?(dbradley)
Yes, we really need this. Please review again.

Thanx,

Jim H. (aka CuriousJ)
I agree with Marcelo Bastos. It's time to close this bug or redefine it as "incorporating FlashGot".
Assignee: cbiesinger → nobody
Target Milestone: mozilla1.6alpha → ---
Product: Core → Firefox
Version: Trunk → unspecified
No assignee, updating the status.
Status: ASSIGNED → NEW
No assignee, updating the status.
No assignee, updating the status.

Closing this as resolved:incomplete, it has been a long time since the last comment and the current Firefox version already have add-on support for download managers. Please re-open this ticket if you consider otherwise.

Status: NEW → RESOLVED
Closed: 24 years ago → 3 years ago
Resolution: --- → INCOMPLETE
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: