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
•