link to non-html docs hosted on server does not work



19 years ago
11 years ago


(Reporter: johng, Assigned: mscott)


Windows 95

Firefox Tracking Flags

(Not tracked)



(1 attachment)



19 years ago
Build 2000071408, win95, pop

- open an email message that includes a link to a non-html document (like a Word
doc) hosted on a server.  Example:
- click on that link

Expected behavior:
- just like in Nav, user should get the dialog that lets the user save it, open
it, pick, app, etc.

Actual behavior:
- nothing seems to happen.  When I right clicked to open the link in a new
window, all I got was a new mail window with the same email message.

Comment 1

19 years ago
Created attachment 11480 [details]
email with the problem

Comment 2

19 years ago
nsbeta3 for consideration
Keywords: nsbeta3
OS: other → Windows 95


19 years ago
QA Contact: lchiang → laurel

Comment 3

19 years ago
hmm - this should be fixed as part of

Comment 4

19 years ago
No this is different. 43661 is implementing open attachment. You click on the
attachment menu, click ont he attachment and select open and it opens it. John's
talking about the case where you are given a url as part of the message that
requires an external helper app. Apparently for him, it isn't automatically
invoking the helper app code when you click on that link.

Comment 5

19 years ago
This actually works for me just fine using a debug build. I think this is a
packaging problem because I don't see the helper app dialog come up at all in
release builds. cc'ing bill law because I've mentioned this problem to him. 

Comment 6

19 years ago
I think I found the packaging problem that was causing the dialog not to work in
release builds. I'm checking in the fix now. Hopefully this will work tomorrow. 

Comment 7

19 years ago
Yes, I investigated this yesterday.  I had to do a releae build and copy over a 
.dll with some debug code to my Win98 box where I was running the official build 
off of sweetlou (my release build wouldn't run properly on the machine where I 
built it; but that's a separate problem probably).

Anyway, what I find is that I get a failure on a call to JS_PushArguments when 
attempting to launch the dialog.  This is before the actual display of the 
dialog so it doesn't appear to be a problem with the chrome/ui.

There is no diagnostic information returned by that function but I think it can 
only fail if the "%ip" format argument is somehow bad.  For example, the QI that 
xpconnect does when converting this interface pointer might be failing for some 

I have to debug further but it's a pain.

I'm going to reopen bug 43583 because I can't see how that will be verified 
while this fails in the release builds.


19 years ago
Last Resolved: 19 years ago
Resolution: --- → FIXED

Comment 8

19 years ago
this was a release packaging problem. I fixed it last night so it works now in
release builds. 

Comment 9

19 years ago
It now brings up dialog to allow to pickApp (not working yet) or save the file. 
There are problems in that the Win32 dialog is different than the other two
platforms... will log bugs with the dialog separately.

Marking this verified.
Using 2000-07-24-08 commercial build with linux rh6.0, NT 4.0 and Mac OS 9.0

Comment 10

19 years ago
hey laurel, what do you mean the pick app dialog doesn't work for you? I'm able
to choose applications from this dialog to handle the application. 
Product: MailNews → Core
Product: Core → MailNews Core
You need to log in before you can comment on or make changes to this bug.