strange interaction between :hover and style.color

RESOLVED WORKSFORME

Status

()

Core
CSS Parsing and Computation
P3
minor
RESOLVED WORKSFORME
17 years ago
15 years ago

People

(Reporter: Vincent, Assigned: dbaron)

Tracking

({testcase})

Trunk
Future
x86
All
testcase
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [CSS1-2.1], URL)

Attachments

(3 attachments)

(Reporter)

Description

17 years ago
When the mouse is on the link text 'Cellule linkable' it changes the colors to
white, but the second time you do it does not change the color text anymore!

French: Quand la souris est sur le lien 'Cellule linkable' ca change la couleurs
du texte en blanc, mais le segonde passage ne change plus la couleur du texte
vers le blanc.

Steps to reproduce:
1.Go with the mouse to text 'Cellule linkable'
2.See it changes the text to white
3.Move the mouse away from the cell
4.Do again step 1
5.It does not changes the text to white anymore WHEN the mouse is on the text
'Cellule linkable' 

It should all the time change the 'Cellule linkable' text to white. It does it
just one time per page loaded.

--
French
Ca devrait changé la couleur du texte 'Cellule linkable' en blanc. Ca le fait
qu'une fois par chargement de page

Comment 1

17 years ago
Please always include build ID in bug reports.
WFM: Works each time with build 2001091708 linux.

Norwegian:
Vær grei å alltid inkludere build ID i bug-rapporter.
WFM: Virker hver gang med build ID 2001091708 linux.
I see this on Win2k, the problem here seems to be that the first time we enter
the text inside the table we do fire the onmouseout for the td, which bubbles
down to the td which calls its event handler that does a
document.links[0].style.color=black, but the text doesn't turn black.

To get the intended behavior you haveto change the JS in the testcase to only
set the link color when you exit the td, i.e. add if (event.target.nodeName !=
'TD') return; as the first thing in the onmouseout handler on the td.

Reassigning to layout since the DOM code does the right thing, it sets the style
of the link to black, but the first time it does that in this testcase the color
of the text doesn't change, most likely due to some weird interaction with the
:hover style rule in this testcase.
Assignee: jst → attinasi
Status: UNCONFIRMED → NEW
Component: DOM HTML → Layout
Ever confirmed: true
QA Contact: stummala → petersen

Comment 3

17 years ago
Punting to style system. Bounce as necessary.
Assignee: attinasi → dbaron
Component: Layout → Style System
QA Contact: petersen → ian
(Assignee)

Comment 4

17 years ago
Created attachment 49986 [details]
simpler testcase
(Assignee)

Comment 5

17 years ago
Created attachment 49987 [details]
simpler still
(Assignee)

Comment 6

17 years ago
I guess I'm having trouble seeing a bug here, other than perhaps one in the
event system.  Once style.color is set, it should override the :hover.  I think
all of the strange behavior is coming from bubbled events.
Created attachment 49995 [details]
even simpler
David, load the latest testcase, move the mouse into the link from underneath
(don't position the mouse inside this link before this), the link turns green,
all is good, then move the mouse down, and the link remains green even if the
onmouseout event did fire (look at the dump), the link should've turned yellow.
After this, when mousing in n' out of the link the colors are backwards, mouse
in, link turns yellow, mouse out and the link turns green.
David, if you take out the <style> element in the testcase the testcase works as
expected.
Interesting... With that last testcase I see the problem with a current cvs
build.  But I don't see it with a 2001-09-14-08 build (both on linux).  So
something broke in the last week....
also works correctly with 2001-09-17-08
Hmm, doesn't work for me with a downloaded 2001-09-14-08 linux build.
OK.  This also worksforme with a downloaded 2001-09-19-08 build, but not with my
own cvs builds (opt and debug) from the same day...  weird.  Ignore my last week
comment.  :)  This is looking more like some sort of race condition....
Bug also occurs on 2001-09-28-03 on Windows 98 SE.
Keywords: testcase
OS: Linux → All
(Assignee)

Updated

17 years ago
Summary: The link color Mozilla version: 2001091311 → strange interaction between :hover and style.color
Whiteboard: [CSS1-2.1]
(Assignee)

Updated

16 years ago
Status: NEW → ASSIGNED
Priority: -- → P3
Target Milestone: --- → Future
fixed by any change somewhere? Add 4 testcases work as expected for me!
Kai, note comments 10-12.  This was all very timing-dependent...

Granted, dbaron's :hover rewrite may have fixed it.
I cannot reproduce the original problem that the color was wrong when the
mouse is over the link, but I do see the opposite problem - the link is keeping
the mouse-over color when moving the mouse outside fast. It's quite easy
to reproduce (2002-08-24-04 trunk Linux):

1. Load URL http://boxfly.free.fr/test/ or attachment 49986 [details]
2. place mouse over "Reload" button and SHIFT-left-click
3. In one sweeping gesture, move the mouse over the link and out the other side
   below it and stop.

At a certain speed of mouse movement the link will stay in it's "highlighted"
state. It looks like 'onmouseout' isn't fired even though 'onmouseover' was.

Should I report this second problem a separate bug and close this one as WFM?
(Assignee)

Comment 19

16 years ago
This bug is very weird and hard to reproduce.  However, if you are seeing a
clearly-separate bug that's easy to reproduce and isn't filed elsewhere, please
file it...
The problem I described in comment 18 is likely bug 130620

The original problem described in this bug is WFM on both Linux and Windows 2000

Comment 21

15 years ago
WFM :/
(Assignee)

Comment 22

15 years ago
Marking worksforme.  There are many things that could have fixed this.
Status: ASSIGNED → RESOLVED
Last Resolved: 15 years ago
Resolution: --- → WORKSFORME

Comment 23

15 years ago
since the bug has been fixed, it should be removed from 
http://www.mozilla.org/docs/web-developer/bugspecs/REC-CSS1.html
You need to log in before you can comment on or make changes to this bug.