215 bytes, text/html
195 bytes, text/html
358 bytes, text/html
2.51 KB, patch
|Details | Diff | Splinter Review|
Please retest with a more recent build. window.status behavior just got changed earlier today... (so test with tomorrow's build).
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.
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.
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. :)
17 years ago
No longer blocks: 110171
-> 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?
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+
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...
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.
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+
Get a module owner/peer r= and propose to drivers.... /be
a=asa (on behalf of drivers) for checkin
-> me, 0.9.8
Assignee: jst → jaggernaut
Target Milestone: mozilla0.9.9 → mozilla0.9.8
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.