236589 - [FIX]mailto: in javascript location command causes exception code 0x80004005 (NS_ERROR_FAILURE)

Status: VERIFIED FIXED

(Core :: DOM: Core & HTML, defect)

Description

[u130342]

User-Agent:       Mozilla compatible
Build Identifier: Mozilla/5.0 (Windows)

this call:
window.location.replace("mailto:[e-mail]?subject=xxx");

causes an exception:

Error: uncaught exception: [Exception... "Component returned failure code:
0x80004005 (NS_ERROR_FAILURE) [nsIDOMLocation.replace]"  nsresult: "0x80004005
(NS_ERROR_FAILURE)"  location: "JS frame :: file:///.../mail.htm :: <TOP_LEVEL>
:: line 39"  data: no]

the problem: Outlook Express 6 (the default mailing app) is opened, but the
script doesn't continue.

Reproducible: Always
Steps to Reproduce:
1. create a htm with a script
window.location.replace("mailto:[e-mail]?subject=xxx");
alert("hi");
2. open it
3. alert never is executed

Actual Results:  
Error: uncaught exception: [Exception... "Component returned failure code:
0x80004005 (NS_ERROR_FAILURE) [nsIDOMLocation.replace]"  nsresult: "0x80004005
(NS_ERROR_FAILURE)"  location: "JS frame :: file:///.../mail.htm :: <TOP_LEVEL>
:: line 39"  data: no]

Expected Results:  
no exception should be raised

Works fine on Mozilla 1.5 and IE6.

Comment 1

[Jason Barnabe (np)]

Confirming on Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7b)
Gecko/20040331 Firefox/0.8.0+ and Mozilla/5.0 (Windows; U; Windows NT 5.1;
en-US; rv:1.7b) Gecko/20040321

Comment 2

[Brendan Eich [:brendan]]

jbird3000: please don't assign probable DOM bugs to the JS engine.  The JS
engine is in C, not C++, and has no XPCOM interface, so it's not going to
produce errors of the sort seen here.

cc listees: any ideas?

/be

Comment 3

[Johnny Stenback (:jst)]

Hmm, I see this in FireFox, but not in my SeaMonkey debug build...

Comment 4

[Boris Zbarsky [:bzbarsky]]

The problem is that nsExtProtocolChannel::AsyncOpen returns NS_ERROR_FAILURE. 
It should probably return some other code (like NS_ERROR_NO_CONTENT or
something) perhaps?  Or even NS_OK?  See
http://lxr.mozilla.org/seamonkey/source/uriloader/base/nsURILoader.cpp#222 --
that's where the exception starts propagating out to the caller.

Harald, please try to list a useful version with bug reports.... that would make
diagnosing problems like this much simpler.

Comment 5

[Christian :Biesinger (don't email me, ping me on IRC)]

(In reply to comment #4)
> The problem is that nsExtProtocolChannel::AsyncOpen returns NS_ERROR_FAILURE. 

eww, it does?

hmm, mailto: does interesting stuff... it actually creates an
inputstreamchannel, with an empty stream... so that leads to onstartr. and
onstopr. getting called.

I'm not quite sure what chatzilla does.. ah. it calls onStartRequest,
synchronously (never calls onstopr. or oda).

both asyncOpens succeed.

> It should probably return some other code (like NS_ERROR_NO_CONTENT or
> something) perhaps?

interestingly, nobody ever returns NS_ERROR_NO_CONTENT in the current seamonkey
tree.

>  Or even NS_OK?  See
> http://lxr.mozilla.org/seamonkey/source/uriloader/base/nsURILoader.cpp#222 --
> that's where the exception starts propagating out to the caller.

I vote for NS_ERROR_NO_CONTENT, as we're never going to call any listener
methods. And the end result should be the same, when called from uriloader, and
for anything else I guess an error is the right thing because no data will ever
come.

Comment 6

[Boris Zbarsky [:bzbarsky]]

> I vote for NS_ERROR_NO_CONTENT

Given the rest of what you said, I second.  White-ballot?  ;)  I wonder why the
mailto channel goes through that ridiculous rigmarole....

Comment 7

[Frankie]

I am seeing a very similar error in Moz 1.8a 2004071408 OSX. This did not occur
in earlier versions (definitely not 1.5 or 1.6, probably not 1.7), so it's
probably the same regression.

The following code:

<script type="text/javascript">
function jhm(address)	{
var site = 'bar.com';
location.href = address + unescape('%40') + site + '?subject=' + document.title;
return false;	}
</script>

<a href="mailto:foo" onclick="return jhm(this.href)">example</a>

results in the following console error:

Error: uncaught exception: [Exception... "Component returned failure code:
0x80004005 (NS_ERROR_FAILURE) [nsIDOMLocation.href]"  nsresult: "0x80004005
(NS_ERROR_FAILURE)"  location: "JS frame :: http://localhost/test.html :: jhm ::
line 17"  data: no]

Consequently, the return statement never fires, which means that two separate
mailto events get sent to my MUA, the javascripted one and the raw href.

Comment 8

[Frankie]

Simplified: <a href="javascript:location.href='mailto:[e-mail]'">TEST</a>

Error: uncaught exception: [Exception... "Component returned failure code:
0x80004005 (NS_ERROR_FAILURE) [nsIDOMLocation.href]"  nsresult: "0x80004005
(NS_ERROR_FAILURE)"  location: "JS frame ::
javascript:location.href='mailto:[e-mail]' :: <TOP_LEVEL> :: line 1"  data: no]

Comment 9

[Boris Zbarsky [:bzbarsky]]

Attachment: Patch as discussed

Comment 10

[Boris Zbarsky [:bzbarsky]]

Comment on attachment 154111 [details] [diff] [review]
Patch as discussed

Note that I am not able to test this patch (I'd need a build with no mailnews
to do that), but it should work based on code inspection.  If someone with a
mailnews-less build can test it, that would be great.

Comment 11

[Christian :Biesinger (don't email me, ping me on IRC)]

Comment on attachment 154111 [details] [diff] [review]
Patch as discussed

callers already deal with it?

couldn't you test with a random scheme that moz can't handle?

Comment 12

[Boris Zbarsky [:bzbarsky]]

But that moz can find an external handler for?  If I could find such, sure...

Comment 13

[Boris Zbarsky [:bzbarsky]]

As for callers dealing, URILoader deals, and other callers will continue to get
an error, as they should.

Comment 14

[Christian :Biesinger (don't email me, ping me on IRC)]

(In reply to comment #12)
> But that moz can find an external handler for?  If I could find such, sure...

user_pref("network.protocol-handler.app.foo", "/usr/bin/xmessage");

Comment 15

[Boris Zbarsky [:bzbarsky]]

Oh, that's what that pref is called.  OK, I've tested and the patch does what it
should.

Comment 16

[Boris Zbarsky [:bzbarsky]]

Comment on attachment 154111 [details] [diff] [review]
Patch as discussed

This is a safe patch worth taking on the branches...

Comment 17

[Asa Dotzler [:asa]]

Comment on attachment 154111 [details] [diff] [review]
Patch as discussed

a=asa

Comment 18

[Boris Zbarsky [:bzbarsky]]

Fixed on aviary (and fixed on trunk earlier today).

Comment 19

[Mike Kaply [:mkaply]]

Comment on attachment 154111 [details] [diff] [review]
Patch as discussed

a=mkaply for 1.7.3

Comment 20

[Boris Zbarsky [:bzbarsky]]

Fixed on 1.7 branch.

Comment 21

[Frankie]

Boris kicks butt.

Comment 22

[Adam Guthrie]

*** Bug 257262 has been marked as a duplicate of this bug. ***