49941 - document.links[0] does not return href string

Status: VERIFIED FIXED

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

Description

[Niko Pavlicek]

From Bugzilla Helper:
User-Agent: Mozilla/4.7 [de] (Win98; I)
BuildID:    2000082204

I've got a OnMouseOver-function on links, which should show a description of the 
link and the URL of the link in the statusbar.

Reproducible: Always
Steps to Reproduce:
1. Go to the example url or the attached page.
2. Move the mouse over one of the links.


Actual Results:  In the statusbar you see the url of the link			
				

Expected Results:  You should see a message with the following architecture:
"descriptive text -- link-url"

In older builds (for example 20000726) you got a message with the following 
architecture:
"descriptive text -- [object HTMLAnchorElement]"

Comment 1

[Niko Pavlicek]

Attachment: Testpage

Comment 2

[Phil Schwartau]

Browser, not engine - reassigning to Event Handling for further triage -

Comment 3

[Heikki Toivonen (remove -bugzilla when emailing directly)]

This is related, if not dup of, to bug 40838.

Comment 4

[Heikki Toivonen (remove -bugzilla when emailing directly)]

This bug has been marked "future" because the original netscape engineer working 
on this is over-burdened. If you feel this is an error, that you or another 
known resource will be working on this bug,or if it blocks your work in some way 
-- please attach your concern to the bug for reconsideration.

Comment 5

[Heikki Toivonen (remove -bugzilla when emailing directly)]

After some more thought I think I will mark this WONTFIX. Explanation: 
document.links[0] is an HTMLAnchorElement object and what we should show in that 
case is [object HTMLAnchorElement] - not the link URL. That is different from NN 
4.x. If you want the URL you need to say document.links[0].href. This works both 
in Mozilla and NN 4.x.

Currently the test case (as it stands) produces a JS error. I have filed bug 
50080 on it.

Comment 6

[Brendan Eich [:brendan]]

I know you may find the DOM level 0 semantics in full ugly, but compatibility
means doing what Nav 2-4.x did.  What does IE do?  If it too returns the full
URL of the link, then I think this bug should be reopened.

I take it the DOM level 0 spec does not specify toString for links.

Adding ekrock.

/be

Comment 7

[Brendan Eich [:brendan]]

Adding vidur too for to check my sanity.

/be

Comment 8

[Heikki Toivonen (remove -bugzilla when emailing directly)]

IE does the same as NN 4.x, that is, displays the link URL.

Comment 9

[Loco]

Updating QA Contact.

Comment 10

[Heikki Toivonen (remove -bugzilla when emailing directly)]

Changing summary. Adding relnote keyword and relnote-devel to status wb.

I am reopening for re-evaluation because we have at least one duplicate.

Comment 11

[Heikki Toivonen (remove -bugzilla when emailing directly)]

*** Bug 58214 has been marked as a duplicate of this bug. ***

Comment 12

[Heikki Toivonen (remove -bugzilla when emailing directly)]

*** Bug 58214 has been marked as a duplicate of this bug. ***

Comment 13

[Heikki Toivonen (remove -bugzilla when emailing directly)]

It is still my opinion that we shouldn't "fix" this. Instead, we should
evangelize the sites that use the bad form. There don't seem to be that many
places that use this bad form.

Comment 14

[Heikki Toivonen (remove -bugzilla when emailing directly)]

Adding Blake to CC in case the decision is to Evangelize.

Comment 15

[Boris Zbarsky [:bzbarsky]]

*** Bug 59876 has been marked as a duplicate of this bug. ***

Comment 16

[Fabian Guisset]

*** Bug 61072 has been marked as a duplicate of this bug. ***

Comment 17

[Heikki Toivonen (remove -bugzilla when emailing directly)]

This isn't really an event bug, (even if this could be considered a bug).
Sending over to DOM Level 0 - you make the call of whether or not we should make
the backwards compatibility fix.

Comment 18

[ekrock's old account (dead)]

Nominating for nsbeta1 consideration. Understand Heikki's point about 
evangelizing sites to fix bad usage. However, here's my take: (1) this worked 
in Nav4.x, so there may be legacy code using it. (2) it also works in IE, so 
the high current market share of that browser will probably induce some people 
to continue using this on an ongoing basis. So I'd say that since both Nav4.x 
b.c. and IE xbrowser compatibility goals point in the same direction, we might 
as well fix this to simplify developers' lives.

Comment 19

[Hixie (not reading bugmail)]

After some investigation, it turns out this is what is causing a bug whereby
Love@AOL displays a "file not found" link.

If you go to the root of the deeply nested frameset that is the search results
page of love@aol:

   http://webcenter.love.aol.com/LoveBrowse/?sx=F&partner=AOW&ct=US&st=TX&lc=TXM

...you'll see the left hand frame has a "Not Found" page. This is caused by the
right hand frame doing:

   var firstHit = document.links[1];
   parent.parent.pic_map.location.href = firstHit;

(This is also mixed in with a race condition so reloading doesn't always trigger
the bug.)

If we are not going to fix this soon, someone at Netscape should file a bug in
Bugscape so that Love@AOL is evangelised.

Comment 20

[Johnny Stenback (:jst)]

I have this fixed (modulo what seems to be an XPConnect bug) on my XPCDOM branch.

Comment 21

[Heikki Toivonen (remove -bugzilla when emailing directly)]

Arun, can you take care of the evangelism task? Regardless of whether we fix
this or not we should advice people to not rely on non-standard stuff.

Based on Ian's observations, plussing and moving to 0.9.1. If the site is
evangelized and fixed before Johnny can have a code fix, I think this could be
minused.

Comment 22

[Johnny Stenback (:jst)]

This is already fixed on the XPCDOM branch, and the DOM spec will most likely be
updated to define this behavior for link elements so I don't thing evangelizing
this is worth while.

Comment 23

[Johnny Stenback (:jst)]

Fixed by the xpcdom landing.

Comment 24

[Prashant Desale]

Verified with 2001-06-05-11.