window.status overwrites URL of link you are hovering over

RESOLVED FIXED in mozilla0.9.8

Status

()

Core
DOM: Core & HTML
P3
normal
RESOLVED FIXED
17 years ago
17 years ago

People

(Reporter: justdave, Assigned: jag (Peter Annema))

Tracking

Trunk
mozilla0.9.8
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(URL)

Attachments

(4 attachments, 1 obsolete attachment)

Mozilla/5.0 (Macintosh; U; PPC Mac OS X; en-US; rv:0.9.6+) Gecko/20011217

If you are hovering over a link, I expect to see the URL of the link I am
hovering over in the status bar.  If the site uses a javascript that does some
sort of animation in the status bar, it quickly overwrites the URL before you
can see it.  window.status should not be allowed to change the status bar while
you are hovering a link, unless it was caused by the onMouseOver event in the
link you are hovering.

Internet Explorer (gack) works this way, and it's quite nice because you can see
where you're going before you go there without having to view the source :-)
Please retest with a more recent build.  window.status behavior just got changed 
earlier today... (so test with tomorrow's build).
(Assignee)

Comment 2

17 years ago
No, actually this is the behaviour I was expecting after my change.

I would need to have a way to tell the difference between window.status set from
onmouseover and window.status set otherwise in order to support both modes.
(Assignee)

Comment 3

17 years ago
Created attachment 63350 [details]
simple test
(Assignee)

Comment 4

17 years ago
Created attachment 63352 [details]
better test, tests setInterval
(Assignee)

Comment 5

17 years ago
So the simple test allows one to see what NS4, IE6 and Mozilla do when
window.status is set from the onload handler, and then from onmouseover/-out on
a <a href>.

NS4, IE6 and Mozilla all show "some text", then when one hovers over the "link",
NS4 and IE6 show the value of the href, while Mozilla (currently) shows the
value of window.status as set from onmouseover.

The setInterval tests sets window.status too "timer text" every 500ms. Mousing
over the "link" in NS4 and IE6 will briefly display the value of the href before
being overridden by the setInterval's window.status change. In Mozilla, the
value of the href is never shown.

Dave, could you provide a test case that shows what you mean, since my own
findings seem to contradict yours.

However, I wouldn't be adverse to changing Mozilla to behave the same as NS4 and
IE6 as described above.
(Assignee)

Comment 6

17 years ago
Created attachment 63353 [details]
test with return true and without
(Assignee)

Comment 7

17 years ago
Created attachment 63354 [details] [diff] [review]
Patch - first step

We'll need this as a first step towards fixing both this and bug 99009. We'll
also need some code that doesn't setOverLink if onmouseover returns true.
The URL where I noticed the problem is at http://www.syndicomm.com/communities/fun/

I actually don't really care what happens with the onMouseOver, I was just
trying to be fair to people. :-)   My main concern is that I want to be able to
see the href for the link when I hover on it.

FWIW, in iCab when there is a window.status from an onMouseOver, it shows the
text from window.status followed by the href in parentheses after it.  Any way
is really acceptible to me as long as I can see the href.  I'll go with whatever
popular opinion is on the rest.
Oh, I haven't had a chance to grab last night's build to test on yet.  I'm on
dialup right now, I'll grab it tonight when I get home when I can do it via
cable. :)
(Assignee)

Comment 10

17 years ago
-> All, all

jst, think you can fix this anytime soon, or should I back out my patch / check
in the above patch in the mean time?
Blocks: 99009
OS: MacOS X → All
Hardware: Macintosh → All
I'm not convinced that what we have now is worse than what we had before your
checkin, I'd feel better leaving it as is for now than backing that out. If we
start getting lots of dupes we should do something about this, but until then I
won't give this very high priority.
Priority: -- → P3
Target Milestone: --- → mozilla0.9.9
Jag, if you're convinced you patch does the right thing, go ahead and check it in.
Comment on attachment 63354 [details] [diff] [review]
Patch - first step

sr=jst
Attachment #63354 - Flags: superreview+
(Assignee)

Comment 14

17 years ago
Hard call. I personally like being able to see the href value when mousing over
links, even if someone has set window.status, but until we get the proper dom0
support it'll be hard to have both this and have window.status from onmouseover
on links. I say let's stick with what we have right now and see how many
complaints we get.
Got a chance to try this with the 2002010308 build, and now the href doesn't
even blink there, it just doesn't show up at all if there's a window.status set.
 This is going the wrong direction...

Comment 16

17 years ago
Using build 2002-01-07-03 and Win2k, I can't see ANY URLs on the status bar any
more... even here in bugzilla.

I think the priority should be to show the URL, without taking into account what
the webpage indicates. If a webpage wants to put a message there all the time,
or scroll it or whatever, fine. But if they want to NOT show the URL destination
(by using a mouseover even on the link, or any other method) that should be
disallowed.

In other words, show me the URL whenever my mouse cursor is over a link. IMHO.
(Assignee)

Comment 17

17 years ago
Created attachment 65580 [details] [diff] [review]
Complete fix.
Attachment #63354 - Attachment is obsolete: true
Comment on attachment 65580 [details] [diff] [review]
Complete fix.

sr=jst
Attachment #65580 - Flags: superreview+

Updated

17 years ago
Attachment #65580 - Flags: review+
Get a module owner/peer r= and propose to drivers....

/be
Comment on attachment 65580 [details] [diff] [review]
Complete fix.

r=bryner

Updated

17 years ago
Keywords: mozilla0.9.8+

Comment 21

17 years ago
a=asa (on behalf of drivers) for checkin
(Assignee)

Comment 22

17 years ago
-> me, 0.9.8
Assignee: jst → jaggernaut
Target Milestone: mozilla0.9.9 → mozilla0.9.8
(Assignee)

Comment 23

17 years ago
Checked in.
Status: NEW → RESOLVED
Last Resolved: 17 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.