266034 - onmouseover return true blocks url being displayed in status bar

Status: RESOLVED DUPLICATE of bug 40838

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

Description

[dolphinling]

If a link has onMouseOver="return true;" the url is not displayed in the status
bar. 

This looks like bug 48317/bug 31997, except those were resolved fixed years ago.
If this is a regression, it occured before 1.7b.

This was originally reported in a comment to bug 265692.

Testcase coming.

Comment 1

[Peter van der Woude [:Peter6]]

Attachment: testcase

see testcase with 3 examples

Comment 2

[Peter van der Woude [:Peter6]]

Attachment: previous case wasn't clean html

Comment 3

[Boris Zbarsky [:bzbarsky]]

Well.. I seem to have found _a_ time this regressed.  Sometime between
2002-01-09-06 and 2002-02-10-06.  Not sure whether it got refixed and
re-regressed since then...

In that range, jag's checkin to nsBrowserStatusHandler.js (revision 1.20) is a
likely culprit...

Comment 4

[Boris Zbarsky [:bzbarsky]]

I tracked this some more.  The problem is that in the |return true;| case the
code in nsGenericHTMLElement::HandleDOMEventForAnchors sees
nsEventStatus_eConsumeNoDefault as the event status (!).  If I return false
instead, I get nsEventStatus_eIgnore.

Those seem very backwards to me.  Returning false is what should put us in the
eConsumeNoDefault status, no?

And in any case, we should be doing the MOUSE_ENTER_SYNTH thing no matter what,
I would think.

Comment 5

[Brendan Eich [:brendan]]

bz: onmouseover is backwards, for reasons that even I don't clearly recall. 
Joki might -- something about wanting return true to affirm that the status is
being set by the handler.  Someone should verify that IE still matches this
backward behavior of Netscape 4.

/be

Comment 6

[Boris Zbarsky [:bzbarsky]]

OK.  So the point, then, is that we should ignore the event status in this code
for MOUSE_ENTER_SYNTH/MOUSE_EXIT_SYNTH events, I guess.

Comment 7

[OstGote!]

see also Bug 40838

Comment 8

[Hussam Al-Tayeb]

I just noticed something. On IE6 SP2, this bug also appears.

I opened https://bugzilla.mozilla.org/attachment.cgi?id=163361&action=view in
IE6SP2 and when I hover with the mouse over the links, nothing is displayed in
the statusbar.

Comment 9

[u58943]

surely this should be blocking 1.0 as its exactly the same security risk and
implications as the bug which brought about this one...
https://bugzilla.mozilla.org/show_bug.cgi?id=265692

Comment 10

[dolphinling]

Requesting blocking-aviary1.0

Comment 11

[chris hofmann]

putting on the radar until we know more

Comment 12

[Jesse Ruderman]

Ewok: this doesn't seem like a security risk to me.  Bug 265692 was only a
"security risk" if you had JavaScript turned off.

Comment 13

[u58943]

huh? Bug 265692 had nothing what so ever to do with javascript and was a 
security risk not being able to see the url you are going to be taken to, this 
bug has the same effect in that you also cannit see the url you are going to, 
hence a security risk as much as Bug 265692 was.

Comment 14

[Johnny Stenback (:jst)]

This is not a security bug, never was, and I don't see how bug 265692 was
either. Browsers have *always* let you prevent displaying the URL in the status
bar using onmouseover handlers etc, that's ancient, and I don't see how this is
a regression  either. IE works like this, so does Firefox, and so does Mozilla
1.4. I don't see anything to fix here at all. Marking INVALID.

Comment 15

[dolphinling]

Woah... whether or not this is a security bug it _is_ still irrational behavior,
and therefore a bug. (Unless we _want_ sites to be able to do this?)

Reopening, though I won't question the blocking flag.

Comment 16

[Johnny Stenback (:jst)]

Sites have *always* been able to do this, IOW we want them to be able to do this
unless we want to change de-facto standard browser behaviour right now. I see
little reason for that. 

Comment 17

[psellhorst]

Resolving this as INVALID is wrong. When dom.disable_window_status_change is
set to "true", sites may NOT directly or indirectly manipulate the status bar
in order to prevent the URL from being displayed.

This bug should be reopened and then marked as a duplicate of bug 40838.
Fixing this would be even better, of course.

Comment 18

[Johnny Stenback (:jst)]

Ah, right you are. Reopening. Sorry for not realizing that earlier, and thanks
for the number of the dupe...

Comment 19

[Johnny Stenback (:jst)]

... and duping. Please followup in bug 40838.

*** This bug has been marked as a duplicate of 40838 ***