44115 - Exception referring to "protocol" property of HTMLAreaElement

Status: VERIFIED FIXED

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

Description

[Bill Law]

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.

Comment 1

[Johnny Stenback (:jst)]

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.

Comment 2

[Johnny Stenback (:jst)]

Attachment: Proposed fix.

Comment 3

[Bill Law]

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?

Comment 4

[Johnny Stenback (:jst)]

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".

Comment 5

[Bill Law]

Thanks for the explanation.  It sounds like your fix will resolve things.

Comment 6

[Jay Patel [:jay]]

Putting on [nsbeta2+] radar for beta2 fix.

Comment 7

[Johnny Stenback (:jst)]

The fix is checked in!

Comment 8

[Jim Roskind]

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.

Comment 9

[John Unruh]

Verified. Works on Mac, Linux, and WinNT.