User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.3) Gecko/20041020 Firefox/1.0 Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.3) Gecko/20041021 Firefox/1.0 When clicking on the eDonkey link on webpage http://www.shareconnector.com/modules.php?name=ed2k&op=viewrelease&id=6574 the relevant eDonkey client (eMule in my case) should launch and attempt to download the file. This does not happen with FireFox versions released on or after 21st October 2004, but works okay with versions dated 20th or earlier. Reproducible: Always Steps to Reproduce: 1. Go to http://www.shareconnector.com/modules.php?name=ed2k&op=viewrelease&id=6574 2. Click on the ed2k:// link in the middle of the page. Actual Results: Nothing happens Expected Results: eMule should open and take link. network.protocol-handler.external.ed2k is set to True, though this problem occurs regardless of this setting. I have only tested the ed2k:// link and it may be that other external protocols are affected.

Using Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.3) Gecko/20041022 Firefox/1.0, external protocol handling does seem to be broken. Using 0.10.1, the "aim me!" link at http://blog.ebrahim.org/ worked fine (it prompted whether or not to allow, and after allowing, it called AIM). Using the build mentioned above, it no longer works (clicking the link produces no effect).

I can confirm this exactly, happens too with current german test build Mozilla/5.0 (Windows; U; Windows NT 5.1; de-DE; rv:1.7.3) Gecko/20041022 Firefox/1.0 didn't happen with last weeks nightlies!

This should definetely be fixed. This one bug will keep me from using firefox as my default browser.

Reporter states that regression window is between 20-21st October (worked on 20th, not on 21st). Possibly due to checkin from bug 264265?

I think it is more likely the checkin for bug 263546 that broke this.

Yes that seems much more likely. mimetypes.rdf (the only file changed in Bug 264265) should have nothing to do with external handlers, as it associates MIME types with actions and not external handlers with actions. Bug 263546 actually changed some stuff with handlers, so that would be a good first place to look.

Guess we don't quite have release candidates yet... this isn't something worthy of blocking release. I have a feeling about bug 263546.

Mine

This was caused by a last-minute interface split prompted by super-review of bug 263546. I guess I lost track of which trees I had tested in.

Fixed on aviary and 1.7. seeking retroactive review and approval because folks are hoping tomorrow's build is the last.

Comment on attachment 163288 [details] [diff] [review] fix regression a=asa for aviary checkin.

Comment on attachment 163288 [details] [diff] [review] fix regression r+sr=darin

(In reply to comment #9) > This was caused by a last-minute interface split prompted by super-review of > bug 263546. I guess I lost track of which trees I had tested in. I now think what happened was that I made the original change then tested after building in uriloader only, forgetting that docshell/build is required. I made the same mistake testing this fix and banged my head for a while trying to figure out why it wasn't helping.

Dan, I'm trying to QA this. Is the External Protocol Request dialog supposed to appear if I haven't already chosen to remember my choice for all links of this type? I'm using the aim me test case in comment #1. The Request dialog appears. I select Launch application. AIM is launched. Is this correct? If so, I can verify this is fixed with Firefox Windows build 2004-10-25-07-0.9

This now appears to be working okay functionally, but I notice that the message that appears does not fit in the box when I select an external link (I used my link from the original log as I do not have AIM installed) - The link is truncated, as is the third paragraph is part way through the word "program" Do you get the same, or is this just me? I am running a screen resolution of 1280 * 1024 and using a tinderbox build of 10:51

(In reply to comment #14) > I'm using the aim me test case in comment #1. The Request dialog > appears. I select Launch application. AIM is launched. Is this correct? hrm, on Linux fc2, I get an alert saying that aim is not a registered protocol. then again, that might be the fault of how my linux box is setup, not firefox. tested with 2004102508-0.9+. how does this behave on Mac OS X?

> hrm, on Linux fc2, I get an alert saying that aim is not a registered protocol. > then again, that might be the fault of how my linux box is setup, not firefox. > tested with 2004102508-0.9+. > > how does this behave on Mac OS X? same behavior on Mac. That is, aim is not a registered protocol.

This patch is to get external protocols back to working the way they were last week. Which protocols are supported is up to your OS and what you've installed on it, the problem this bug is fixing is that they wouldn't launch at all. The "not a registered protocol" message comes up before the buggy part I fixed, so to test you do need to try something that is registered with your OS. I don't know what's common on linux.

(In reply to comment #18) > I don't know what's common on linux. Dan, thanks for the clarification! yeah, there wasn't an app defined on my linux box (by default) to handle aim, so I set it up to use gaim --and then the test in comment 1 worked for me (got the external protocol request dialog, hit launch app, gaim launches).

(In reply to comment #17) > > how does this behave on Mac OS X? > same behavior on Mac. That is, aim is not a registered protocol. finally turned on the mac here and got today's build (2004102506-0.9+): I do get the external protocol request dlg, and clicking launch app does open iChat. I'm running 10.3.5, but Tracy perhaps you're on 10.2.8 and that might be the setup difference? (you'd think that iChat would be the default aim handler on 10.2 and later...) cannot seem to find the place in iChat which allows me to change the launch preferences, hrm.

Okay, thanks Dan. Verifying this against Mac and Windows Firefox builds this morning and Sarahs comments on linux. Soothsayer, the truncated text issue is a known bug in many dialogs. I can't find it, although I am fairly certain it exists.

(In reply to comment #21) > Soothsayer, the truncated text issue is a known bug in many dialogs. I can't > find it, although I am fairly certain it exists. sounds like bug 260292.