Closed
Bug 44115
Opened 24 years ago
Closed 24 years ago
Exception referring to "protocol" property of HTMLAreaElement
Categories
(Core :: DOM: Core & HTML, defect, P3)
Core
DOM: Core & HTML
Tracking
()
VERIFIED
FIXED
M17
People
(Reporter: law, Assigned: jst)
References
()
Details
(Whiteboard: [nsbeta2+][HAVE FIX][ETA 7/11])
Attachments
(1 file)
(deleted),
patch
|
Details | Diff | Splinter Review |
You can experience this bug by going to the referenced URL and right-clicking on
the pseudo-menu on the left hand side (e.g., on the "Quick News" bar.
You will get an exception like this (your line number will vary because I've got
some debugging code in my version of this file):
[Exception... "<no message>" code: "-2142568438" nsresult: "0x804b000a
<unknown>)" location: "chrome://navigator/content/nsContextMenu.js Line: 284"]
The line in question is:
if ( !link.protocol ) {
I've determined that "link" is [object HTMLAreaElement], which does not have a
protocol property. But the test is for existence of that property (and the code
goes on to use link.href if link.protocol isn't present; HTMLAreaElement does
have a href property).
I believe that "link.protocol" should be undefined and this code should work
without throwing an exception.
I'm not sure if this is DOM level 0 or DOM level 1. Also, it could be a JS
thing. But I'll let somebody else sort that out.
Assignee | ||
Comment 1•24 years ago
|
||
Mozillas version of HTMLAreaElement does (indirectly) have a protocol property,
the problem is that nsHTMLAreaElement doesn't absolutize the URL properly so if
the URL in an area element is relative we're unable to produce a URI from which
we can ask what the protocol is.
I have a fix for this and it's really simple and low risk (more or less just a
copy of what's done in nsHTMLAnchorElement), I'm nominating this for nsbeta2 and
IMO this should be marked nsbeta2+.
I'll attach the patch.
Status: NEW → ASSIGNED
Component: DOM Level 1 → DOM Level 0
Keywords: nsbeta2
Target Milestone: --- → M17
Assignee | ||
Comment 2•24 years ago
|
||
Assignee | ||
Updated•24 years ago
|
Whiteboard: [HAVE FIX]
I'm sorry; I must not have been clear in my previous comment about what I'm
seeing.
I get a JS exception in attempting to reference the protocol property of an
HTMLAreaElement object. That's the problem I was talking about, which seems, to
me, to be orthogonal to the issue of what the .href property might resolve to.
Your patch (which I welcome, by the way :-) seems to fix the problem with the
href property. But we won't even get that far since the script in question
barfs previously when referencing the protocol property.
I can work around this by wrapping the reference to the protocol property with a
try/catch, but I don't think I should have to do that, should I?
Assignee | ||
Comment 4•24 years ago
|
||
I'm sorry, your explanation was clear, but my responce wasn't.
Here's how this works:
To get the protocol from an HTMLAreaElement we get the string representation of
the URI and we construct an nsIURI implementation from which we ask what the
protocol (sheme) is. When we do that in the current mozilla code we simply get
the value of the "href" *attribute* (by calling GetHref()), and then we try to
construct the nsIURI from that by calling NS_NewURI() passing the value of the
"href" attribute as an argument. This does work just fine as long as the value
of the "href" attribute is an complete absolute URL (i.e.
"http://www.mozilla.org"). As long as that's true you can access the .protocol
property on a HTMLAreaElement without getting the exception, but if the value if
the "href" attribute happens to be a relative URL (i.e. "/foo/bar") the call to
NS_NewURI() inside the protocol property getter will fail and the failure code
from that call is returned out to the JS and you get that as an exception.
My fix is to make sure that we always get an absolute URI from GetHref(), thus
the call to NS_NewURI() won't fail and you don't get the exception any more.
My fix also fixes similar problems with the properties "search", "host",
"hostname", "pathname", "port" and "hash".
Thanks for the explanation. It sounds like your fix will resolve things.
Comment 6•24 years ago
|
||
Putting on [nsbeta2+] radar for beta2 fix.
Whiteboard: [HAVE FIX] → [nsbeta2+] [HAVE FIX]
Assignee | ||
Updated•24 years ago
|
Whiteboard: [nsbeta2+] [HAVE FIX] → [nsbeta2+][HAVE FIX][ETA 7/11]
Assignee | ||
Comment 7•24 years ago
|
||
The fix is checked in!
Status: ASSIGNED → RESOLVED
Closed: 24 years ago
Hardware: PC → All
Resolution: --- → FIXED
Comment 8•24 years ago
|
||
Verified on Windows NT, using build 2000080204 (an M17 beta2 branch build) that
right clicking on the "quick news" item in the test URL does not throw an exception.
This still needs to be verified on other platforms, but I bet the code is pretty
XP consistent.
You need to log in
before you can comment on or make changes to this bug.
Description
•