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

VERIFIED FIXED

Status

()

Core
DOM: Core & HTML
--
major
VERIFIED FIXED
14 years ago
12 years ago

People

(Reporter: Harald, Assigned: bz)

Tracking

({fixed-aviary1.0, fixed1.7.5, regression})

Trunk
fixed-aviary1.0, fixed1.7.5, regression
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(URL)

Attachments

(1 attachment)

(Reporter)

Description

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

this call:
window.location.replace("mailto:xxx@yyy.td?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:xxx@yyy.td?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

14 years ago
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
Assignee: firefox → general
Status: UNCONFIRMED → NEW
Component: General → JavaScript Engine
Ever confirmed: true
Keywords: regression
Product: Firefox → Browser
QA Contact: pschwartau
Summary: when opening a mailto: link by a javascript command window.location.replace("mailto:xxx@yyy.td?subject=xxx") always an exception with errror 0x80004005 (NS_ERROR_FAILURE) is raised → when opening a mailto: link by a javascript command window.location.replace("mailto:xxx@yyy.td?subject=xxx") always an exception with errror 0x80004005 (NS_ERROR_FAILURE) is raised
Version: unspecified → Trunk
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
Assignee: general → general
Component: JavaScript Engine → DOM: Level 0
Hmm, I see this in FireFox, but not in my SeaMonkey debug build...
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.
(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.
> 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....
Blocks: 48376
No longer blocks: 48376

Comment 7

14 years ago
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.
OS: Windows XP → All
Hardware: PC → All

Comment 8

14 years ago
Simplified: <a href="javascript:location.href='mailto:one@two.com'">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:one@two.com' :: <TOP_LEVEL> :: line 1"  data: no]
Summary: when opening a mailto: link by a javascript command window.location.replace("mailto:xxx@yyy.td?subject=xxx") always an exception with errror 0x80004005 (NS_ERROR_FAILURE) is raised → mailto: in javascript location command causes exception code 0x80004005 (NS_ERROR_FAILURE)
Created attachment 154111 [details] [diff] [review]
Patch as discussed
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.
Attachment #154111 - Flags: superreview?(darin)
Attachment #154111 - Flags: review?(cbiesinger)
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?
Attachment #154111 - Flags: review?(cbiesinger) → review+
But that moz can find an external handler for?  If I could find such, sure...
As for callers dealing, URILoader deals, and other callers will continue to get
an error, as they should.
(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");
Oh, that's what that pref is called.  OK, I've tested and the patch does what it
should.

Updated

14 years ago
Assignee: general → bzbarsky
Summary: mailto: in javascript location command causes exception code 0x80004005 (NS_ERROR_FAILURE) → [FIX]mailto: in javascript location command causes exception code 0x80004005 (NS_ERROR_FAILURE)

Updated

14 years ago
Attachment #154111 - Flags: superreview?(darin) → superreview+
Comment on attachment 154111 [details] [diff] [review]
Patch as discussed

This is a safe patch worth taking on the branches...
Attachment #154111 - Flags: approval1.7.2?
Attachment #154111 - Flags: approval-aviary?

Comment 17

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

a=asa
Attachment #154111 - Flags: approval-aviary? → approval-aviary+
Fixed on aviary (and fixed on trunk earlier today).
Status: NEW → RESOLVED
Last Resolved: 14 years ago
Keywords: fixed-aviary1.0
Resolution: --- → FIXED

Comment 19

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

a=mkaply for 1.7.3
Attachment #154111 - Flags: approval1.7.3? → approval1.7.3+
Fixed on 1.7 branch.
Keywords: fixed1.7.3

Comment 21

13 years ago
Boris kicks butt.
Status: RESOLVED → VERIFIED

Comment 22

12 years ago
*** Bug 257262 has been marked as a duplicate of this bug. ***
You need to log in before you can comment on or make changes to this bug.