24974 - Inconsistency in functioning of onMouseOver

Status: RESOLVED WORKSFORME

(Core :: DOM: UI Events & Focus Handling, defect, P3)

Description

[Finn E. Theodorsen]

Windows NT 4.00.1381
Mozilla 200001 2208 / 5.0.0.00022 of 21-1-1999

Inconsistency in functioning of onMouseOver ?

onMouseOver="window.status='xxxxx'"
value in <A HREF> tag does not display,
instead linkaddress is displayed in status
line as usual.

If focus is taken away from Mozilla to another
window and then back, the 'xxxxx' IS displayed.

//F.E.Theodorsen

(Sorry! Nu URL - found on page in intra-net)

Comment 1

[harishd]

Attachment: Test case generated from the problem described.

Comment 2

[harishd]

This is what I noticed:

1) Yup, window.status on <A> does not work.

2)Moving the mouse away from the browser ( mozilla ) window and bring it back on 
  the link displays 'xxxxx'...but not always.  

Comment 3

[harishd]

CCing myself.

Comment 4

[Finn E. Theodorsen]

What I meant by:
"If focus is taken away from Mozilla to another
window and then back, the 'xxxxx' IS displayed."
is that I placed the mouse over the link, and used SHIFT+TAB twice
to shift focus to another (non-mozilla) window and back again,
without moving the mouse - for me this shows the 'xxxxx' text in the
status line every time - so the problem might be in the order it determines
what to do when the mouse is placed over a link.

Comment 5

[harishd]

Marking it M16.

Comment 6

[joki (gone)]

Bulk prioritizing bugs for correct milestones.

Comment 7

[Nisheeth Ranjan]

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

Comment 8

[joki (gone)]

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 reconsideratio=6905

Comment 9

[ckritzer (gone)]

Mass update:  changing qacontact to [e-mail]

Comment 10

[Loco]

Updating QA Contact.

Comment 11

[Hixie (not reading bugmail)]

Reassigning QA Contact for all open and unverified bugs previously under Lorca's
care to Gerardo as per phone conversation this morning.

Comment 12

[Madhur Bhatia]

QA contact updated

Comment 13

[Cynthia]

The link has the same result in IE 5.5 for me.  On mouse over, shows the URL, on 
mouse away, shows xxxxxx, but I am assuming due to the fact that when I 
click on the link that it serves up a page not found that it is because the 
link has not been created as a null link, and thinks that it needs to serve up 
another page and therefore shows the URL in IE. 

What I have found is that Netscape does not handle mouse behaviors correctly 
when the text or graphic with a null link applied is contained within a layer.  
On mouse over you see the URL, on mouse away you see the text that was supposed 
to be displayed, just like in the example of xxxxx that is attached to this.

IE handles this correctly, and realizes that there is a null link and will place 
text in the status bar if that behavior has been requested on mouse over, or 
nothing at all if it hasn't, which is exactly how the behavor should work.  IE 
never places the URL in the status bar for a null link, since it is meaningless. 
Netscape however forces something to be placed in the status bar, and then does 
not handle the behavor correctly.  If you leave the null link as a # you get the 
URL in the status bar.  If you change it to javascript:; you get the word 
javascript:; in the status bar.  If you change it to any other text, you get the 
URL, and the text that you typed in the status bar.  

It would be really nice if Netscape would handle null links that are contained 
within layers properly.  Netscape handles null links properly outside of layers. 

Comment 14

[dylang]

Related bugs:
http://www.kuro5hin.org/comments/2002/11/24/225746/27/7#7

First comment has a Javascript which is supposed to close the window.  It won't
do this with the JS prefs I have (everything unchecked, except change images). 
However, the third one (comment id #9) with the link "this" will succesfully
open a new window without permission to do so.

It seems very inconsistent that with open unrequested off, mouseover can still
load new windows.  And that the window.close in the exact same way doesn't work.

Comment 15

[idomoggie]

I have this bug in Camino Build ID: 2003043015 too.

Comment 16

[Pham]

.

Comment 17

[Marc Boucher]

From what I see elsewhere 
onMouseOver="window.status='xxxxx'"
should be written 
onMouseOver="window.status='xxxxx'; return true;"
to work in all browsers (IE, NS4, Gecko).

Comment 18

[Richard York]

Related to this bug:
The onmouseover event in Mozilla is not consistent, this also effects the :hover
pseudo class as well.  Visit http://www.smilingsouls.net, Opera and IE both
agree on handling of the onmouseover there as well as the :hover pseudo class. 
This seems to me to be a limitation in the way Gecko handles the onmouseover
event in general, and not limited to setting the window status.

Comment 19

[Hsin-Yi Tsai (she/her) | away [:hsinyi]]

WORKSFORME now, Fx 125 on Win 11.