Closed
Bug 236589
Opened 21 years ago
Closed 20 years ago
[FIX]mailto: in javascript location command causes exception code 0x80004005 (NS_ERROR_FAILURE)
Categories
(Core :: DOM: Core & HTML, defect)
Core
DOM: Core & HTML
Tracking
()
VERIFIED
FIXED
People
(Reporter: u130342, Assigned: bzbarsky)
References
()
Details
(Keywords: fixed-aviary1.0, fixed1.7.5, regression)
Attachments
(1 file)
1.17 KB,
patch
|
Biesinger
:
review+
darin.moz
:
superreview+
asa
:
approval-aviary+
mkaply
:
approval1.7.5+
|
Details | Diff | Splinter Review |
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•21 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
Comment 2•21 years ago
|
||
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
Comment 3•21 years ago
|
||
Hmm, I see this in FireFox, but not in my SeaMonkey debug build...
Assignee | ||
Comment 4•21 years ago
|
||
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•21 years ago
|
||
(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.
Assignee | ||
Comment 6•21 years ago
|
||
> 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....
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
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)
Assignee | ||
Comment 9•20 years ago
|
||
Assignee | ||
Comment 10•20 years ago
|
||
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 11•20 years ago
|
||
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+
Assignee | ||
Comment 12•20 years ago
|
||
But that moz can find an external handler for? If I could find such, sure...
Assignee | ||
Comment 13•20 years ago
|
||
As for callers dealing, URILoader deals, and other callers will continue to get
an error, as they should.
Comment 14•20 years ago
|
||
(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");
Assignee | ||
Comment 15•20 years ago
|
||
Oh, that's what that pref is called. OK, I've tested and the patch does what it
should.
Assignee | ||
Updated•20 years ago
|
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•20 years ago
|
Attachment #154111 -
Flags: superreview?(darin) → superreview+
Assignee | ||
Comment 16•20 years ago
|
||
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•20 years ago
|
||
Comment on attachment 154111 [details] [diff] [review]
Patch as discussed
a=asa
Attachment #154111 -
Flags: approval-aviary? → approval-aviary+
Assignee | ||
Comment 18•20 years ago
|
||
Fixed on aviary (and fixed on trunk earlier today).
Comment 19•20 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+
Comment 22•19 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.
Description
•