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.

not familiar with this... pls punt back --or to the appropriate component-- if ActiveX is the wrong one.

This is by design.

Marking 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/

Changing description, reassigning.

4xp issue

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

nav triage team: We should do this, marking nsbeta1, mozilla0.9.1, reassigning to law

*** 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: "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.

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 :)

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.

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.

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.

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.

spam: over to 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

*** 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).

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. ***

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).

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)

oops, really taking

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.

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.

this includes the changes to existing files

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

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...

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

Comment on attachment 135347 [details] [diff] [review] patch part 1 v2 Looks like the right idea but trying someone who might actually understand COM ;-)

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.

Would someone cvs add the new files and provide a diff with the new files in the diff rather than providing them separately?

(does not differ from v2, except merged to trunk)

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.

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."

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.

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".

No assignee, updating the status.

No assignee, updating the status.

No assignee, updating the status.