Closed Bug 38380 Opened 24 years ago Closed 22 years ago

[ESM/CSS] css a:hover ignored on link with javascript "onMouseover" and "return true;"

Categories

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

defect

Tracking

()

VERIFIED FIXED
mozilla0.9.9

People

(Reporter: doronr, Assigned: jag+mozilla)

References

Details

(5 keywords, Whiteboard: [rtm-])

Attachments

(4 files)

If a link has the javascript onMouseover code in it and that document has css
defined, the css for the link is overriden. Attaching test case.

Assigning to style system, but could be js engine. Could not find a smiliar bug.
Attached file testcase of bug
I think what you're saying is that mozilla "forgets" to update a link with the 
a:hover style information if the link has onmouseover code.  Modifying summary 
to make that more clear.
Summary: link with javascript "onMouseover" overides css → css a:hover ignored on link with javascript "onMouseover"
The correct component here is probably "Event Handling".
--> even handling, per David Baron's remark. Thanks!
Assignee: pierre → joki
Component: Style System → Event Handling
QA Contact: chrisd → janc
The problem comes from the "return true;" at the end of the onMouseOver and 
onMouseOut handlers. If you remove them, it works (I'm going to attach a 
testcase). Reassigned to jst to check the syntax. I'm not a JS/DOM expert and 
don't know whether it's correct to put a "return true" in the handlers.
Assignee: joki → jst
Component: Event Handling → DOM Level 1
Attached file testcase that works
This is indeed an event handling problem, from looking at the code the event

state manager sets the hover state *after* the content object has handled the

event and it sets the state only if the eventhandler doesn't return true (i.e.

if the event state is different than nsEventStatus_eConsumeNoDefault), this is

IMO wrong, but I'll let Tom Pixley decide on that...

Assignee: jst → joki
Component: DOM Level 1 → Event Handling
*** Bug 42163 has been marked as a duplicate of this bug. ***
Its a hard call but in this case I agree with you, the :hover should fire 
regardless of the return from the DOM handling.  I can think of cases where I'd 
like to be able to control css pseudo-class setting from DOM event code but I 
suppose you can just directly add/remove the pseudo-class and get the same 
effect.
Status: NEW → ASSIGNED
In case I don't get back to this right away the fix is somewhat more difficult 
than it seemed.  The tracking of the nsEventStatus_eConsumeNoDefault event state 
is currently what allows the use of the :hover state on the link, not the text 
underneath it.  This makes it very related to bug 5693
Depends on: 5693
Adding [ESM/CSS] prefix to bugs in EventStateManager with its generated events 
or CSS pseudo-class management.
Summary: css a:hover ignored on link with javascript "onMouseover" → [ESM/CSS] css a:hover ignored on link with javascript "onMouseover"
small note - the summary seems a bit misleading, as the return true; part is
missing. Adding this to the summary.
Summary: [ESM/CSS] css a:hover ignored on link with javascript "onMouseover" → [ESM/CSS] css a:hover ignored on link with javascript "onMouseover" and "return true;"
*** Bug 45779 has been marked as a duplicate of this bug. ***
*** Bug 45604 has been marked as a duplicate of this bug. ***
Mass update:  changing qacontact to ckritzer@netscape.com
QA Contact: janc → ckritzer
*** Bug 47955 has been marked as a duplicate of this bug. ***
Per heikki, saari, ckritzer:
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.
Target Milestone: --- → Future
Keywords: testcase
Eol - this is the bug that you hit.
Ian "Hixie" Hickson has told me of a temp fix for this (I am Eol from his above
comments).  Thought I should post it so that others with this problem who
stumble across this bug report can work around it till the bug is actually
fixed.  Change "return true" to "return false".  CSS a:hover attributes will
then work along with the javascript "onMouseover" tag.
I think ALL css/html 4/javascript/DOM bugs mustn't be marked as "Future" because
it is an aim of Mozilla 1.0 (and also Netscape 6) to have a standard compliant
browser, so there shouldn't be any known bugs you hadn't really tried to fix it
when you release it.
Especially not bugs which MANY web designers will see and will angry about!
According to my JavaScript references, returning false to an onMouseOver event 
should void the result of the event.  But Moz obviously does not conform to 
this behavior, otherwise the above workaround would not work.

This appears to be a related issue.

a:hover, of course, should be unaffected by what onMouseOver returns.
Updating QA Contact.
QA Contact: ckritzer → lorca
OK, I'm nominating this for rtm because it breaks renting DVD's on netflix,
which is a very popular site. See bug 54113
Keywords: rtm
*** Bug 54113 has been marked as a duplicate of this bug. ***
adding interested parties to cc list.
changing priority to p2, otherwise pdt will never look at it.
Priority: P3 → P2
Sorry, folks.  This isn't high priority enough for the rtm branch.  Marking
future, evangwanted, and rtm-.
Keywords: evangwanted
Whiteboard: [rtm-]
Could someone verify that this causes 54113?  If it does, what would it take to
reconsider fixing this? Is it because it's too complicated of a fix or because
there's not enough engineering time that this was futured and rtm-'d? I really
want Netflix.com to work and I think it would be a shame if it didn't.
I would be happy to try to help on this, though I know nothing about any of the
technologies involved. Or is this just considered so unimportant that we
wouldn't take a fix even if we had one?
Hyatt said on bug 5693:  "IE5 puts the links into :hover even when true is 
returned from onmouseover.  I think we should do the same."

I agree.
I have a trivial patch that fixes this bug.
BTW, a justification for doing things the way this bug suggests (to respond to 
timeless@bemail.org 's comments on bug 5693) is that :hover is a state rather 
than an action.  According to CSS2,
http://www.w3.org/TR/REC-CSS2/selector.html#dynamic-pseudo-classes ,

  The :hover pseudo-class applies while the user designates an element (with
  some pointing device), but does not activate it.

It happens that an element entering and leaving the :hover state is *somewhat* 
related to mouseover/mouseout events (see bug 5693 for the messy details).  
However, entering or exiting the :hover state is a state change required by the 
CSS spec unrelated to the mouseover/mouseout events.  (Admittedly, this means it 
can't be implemented in terms of the DOM event model, but I don't think it 
should be possible for JS to mess things up so things stay in :hover -- it 
messes up the cascade quite seriously.)
As David (Hyatt, not Baron!) and I discussed this afternoon, CSS and the DOM
are totally unrelated for this issue. They may be similar, but they do not 
affect each other in any way.

If you want to override the :hover style then don't set it, or set it at the
same time as setting the relevant element style, eg:

   :link, :visited { ... }

...will override any link hover colouring rules present in ua.css, and:

   div, div:hover { ... }

...will ensure that the rules set for div do not change when the div is in the
:hover state (assuming no rule of higher specificity is present in the same 
cascade level).
ass this seems to kill some major sites, perhaps this could go into trunk and
then maybe into branch?
If hyatt has a trivial fix, can we [rtm need info] this and try to get it into
the branch?  I really want to be able to use Netflix :)
yes, please, my queue is almost empty!
For renomination, we need hyatt's path and r='s I believe.
Hyatt can you attach your patch so we can at least test it? Appreciate it.
Pinging Hyatt
This seemed to be the right place to post, being the only result in a search 
for a:hover. I have not used Bugzilla before, so apoligies if any are due :o)

I am using the windows binary of M18 on windows 98, and the 'test case that 
works' (referenced in the attachments above) does not work for me.  Neither do 
several other sites I have tested (some with onMouseOver events and some 
without).  Even adding a DocType definition of HTML 4 Transitional (to get 
Mozilla out of quirk rendering mode) does not make the test case work - the 
a:hover pseudo class just does not seem to work for me.
bugzilla.mozilla@oreilly.cx: this is a known bug, and was fixed post m18. In
fact, this actually bug depends on that particular bug (5693).  You should try a
new nightly build that you can get off mozilla.org's man page.
*** Bug 62531 has been marked as a duplicate of this bug. ***
Keywords: evangwanted
QA Contact: lorca → gerardok
Reassigning QA Contact for all open and unverified bugs previously under Lorca's
care to Gerardo as per phone conversation this morning.
I'm confused by Doron Rosenberg's comments that this was fixed post-m18. It's
still broken with build 2001022805 WinNT (as in the first testcase does not show
the hover effect as it should). Was Hyatt's "trivial patch" ever checked in? Was
there a regression?
*** Bug 70660 has been marked as a duplicate of this bug. ***
I was talking about a:hover bug the reporter mentioned. sorry for the confusion
The netflix page seems to be working fine (tested on a Windows build from this
week).

Gerardo, could we get some test coverage on the current situation, what
platforms etc?
Keywords: nsbeta1nsbeta1-, qawanted
Does the "trivial fix" that Hyatt mentioned last October still exist? Can we get
a look at it and get this one fixed?

The testcase still fails with the 2001040304 build on WinNT4. Netflix may have
changed the site.
Yeah, this is trivial to fix.  Do you want me to take the bug?
Here you go ;)
Assignee: joki → hyatt
Status: ASSIGNED → NEW
Target Milestone: Future → ---
Status: NEW → ASSIGNED
Target Milestone: --- → mozilla0.9.1
*** Bug 77332 has been marked as a duplicate of this bug. ***
removing old keywords.  Nominating for beta1 and mozilla0.9.1, especially as
this has an easy fix!
Target Milestone: mozilla0.9.1 → mozilla0.9.2
This doesn't fit the profile for 0.9.2, but could still be landed in 'limbo'. 
->0.9.3
Target Milestone: mozilla0.9.2 → mozilla0.9.3
QA contact updated
QA Contact: gerardok → madhur
top100: happens on links to external sites at http://www.altavista.com/, because
Altavista uses mouseovers to hide the fact that links to external sites are
routed through a counter script.
Keywords: top100
Target Milestone: mozilla0.9.3 → mozilla0.9.4
*** Bug 92855 has been marked as a duplicate of this bug. ***
Marking mostfreq at 10 dups.
Keywords: mostfreq
r=bryner
sr=waterson
Fixed.
Status: ASSIGNED → RESOLVED
Closed: 23 years ago
Resolution: --- → FIXED
verified on build 2001-08-06-trunk
Status: RESOLVED → VERIFIED
http://www.dvdboard.de/FAQ/ upper frame mouseover still doesn't work - can
someone verify and reopen the bug?
That's failing for a different reason... my guess would be the tag name check
perhaps?

At any rate, it isn't the same bug as this one, which addressed a particular
type of mouseover problem.
The other page is doing hovers with js event handlers (which is sheer
genius: why use 'A:hover' when a bunch of fragile code will do!!)
 
The JS is specific to IE's model, although it's not anything that
can't be done in the W3C model (but need to use some other way to set
up an event listener for the document, need to pass |event| as an arg 
to the handlers, need to use "target/relatedTarget" instead of 
"toElement/fromElement", etc.)

But for this bug, the testcase 5/19 is working in 8/10 win32/linux/mac.
so I'm reopening my old bug 92855 then!
David, could we get this on 0.9.2 branch?
Keywords: topembed
Doesn't work for me in build 2002012903/Win2000

might be regression connected to the checking-in fix for bug 990099.
Sorry, the bug number in previous comment should be bug 99009
I can confirm this bug exists in 0.9.8 Windows (2000) release (Build ID: 2002020406)
Status: VERIFIED → REOPENED
Resolution: FIXED → ---
I see this in linux nightly trunk build 2002-02-02-22 and linux CVS build from
2002-02-06 as well.  OS -> ALL.  Backing out the patch to bug 99009 does not help.
OS: Windows 98 → All
Hardware: PC → All
*** Bug 125221 has been marked as a duplicate of this bug. ***
-> me, regression, -> 0.9.9, nsbeta1
Keywords: nsbeta1, regression
Target Milestone: mozilla0.9.4 → mozilla0.9.9
-> me, really.
Assignee: hyatt → jaggernaut
Status: REOPENED → NEW
Comment on attachment 69428 [details] [diff] [review]
Only skip status setting text, not other side effects

sr=jst
Attachment #69428 - Flags: superreview+
Comment on attachment 69428 [details] [diff] [review]
Only skip status setting text, not other side effects

r=bryner
Attachment #69428 - Flags: review+
nsbeta1+ per ADT triage team
Keywords: nsbeta1nsbeta1+
Checked this in Feb 13.
Status: NEW → RESOLVED
Closed: 23 years ago22 years ago
Resolution: --- → FIXED
*** Bug 129828 has been marked as a duplicate of this bug. ***
For the record, the fix for this bug is modified in the fix for bug 5693 (which
removes the hack in nsGenericHTMLElement::HandleEventForAnchors and thus moves
the fix for this bug into the ESM).
QA Contact: madhur → rakeshmishra
in the mean time, VERIFIED FIXED using attachment 8389 [details].
Status: RESOLVED → VERIFIED
Mass removing self from CC list.
Now I feel sumb because I have to add back. Sorry for the spam.
Keywords: qawanted
Component: Event Handling → User events and focus handling
You need to log in before you can comment on or make changes to this bug.