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

Status: VERIFIED FIXED

(MailNews Core :: Backend, defect, P3)

Description

[johng]

Build 2000071408, win95, pop

Reproduce:
- open an email message that includes a link to a non-html document (like a Word
doc) hosted on a server.  Example:
http://client/seamonkey/launch/reviewers_guide/master_pr2.doc
- 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

[johng]

Attachment: email with the problem

Comment 2

[johng]

nsbeta3 for consideration

Comment 3

[lchiang]

hmm - this should be fixed as part of 
http://bugzilla.mozilla.org/show_bug.cgi?id=43661.

Comment 4

[Scott MacGregor]

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

[Scott MacGregor]

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

[Scott MacGregor]

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

[Bill Law]

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

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.

Comment 8

[Scott MacGregor]

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

Comment 9

[laurel]

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

[Scott MacGregor]

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.