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

VERIFIED FIXED

Status

P3
normal
VERIFIED FIXED
19 years ago
11 years ago

People

(Reporter: johng, Assigned: mscott)

Tracking

Trunk
x86
Windows 95

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

(Reporter)

Description

19 years ago
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.
(Reporter)

Comment 1

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

Comment 2

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

Updated

19 years ago
QA Contact: lchiang → laurel

Comment 3

19 years ago
hmm - this should be fixed as part of 
http://bugzilla.mozilla.org/show_bug.cgi?id=43661.
(Assignee)

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

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

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

Updated

19 years ago
Status: NEW → RESOLVED
Last Resolved: 19 years ago
Resolution: --- → FIXED
(Assignee)

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
Status: RESOLVED → VERIFIED
(Assignee)

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.