Open Bug 1618190 Opened 4 years ago Updated 2 years ago

CSS animation on hover on list items leaves a trail when done quickly over multiple elements


(Core :: CSS Transitions and Animations, defect, P3)

75 Branch



Tracking Status
firefox-esr68 --- wontfix
firefox73 --- wontfix
firefox74 --- wontfix
firefox75 --- fix-optional


(Reporter: sangeethmanayil, Unassigned)




(Keywords: regression)


(3 files)

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:75.0) Gecko/20100101 Firefox/75.0

Steps to reproduce:

  1. Visit
  2. Hover over a blog post list item and notice the flashing color animation.
  3. Hover over multiple blog post titles grouped together from top to down or vice-versa quickly

Actual results:

Notice the trail of animation left on elements which are not hovered over anymore.

Tested on:
Firefox Nightly 75.0a1 (2020-02-25)
Firefox 73.0.1 (64-bit)

Expected results:

Should only show the animation on the item currently being hovered over.

Works as expected on:

Chrome 80.0.3987.122
Safari 13.0.5 (15608.5.11)

Attached file reduced.html
Component: Untriaged → CSS Transitions and Animations
Product: Firefox → Core
Has STR: --- → yes
Ever confirmed: true
Keywords: regression

I think Firefox is right on this one, note that there's both a transition and an animation. Removing the any of both makes it work as expected.

But worth checking with Brian?

Flags: needinfo?(brian)

Regression window (layout.css.servo.enabled = true):

Regressed by:
79c73def3bdf45398212e2cd53137667098d560f Stone Shih — Bug 1392876 - Enable coalescing mouse events to be once per refresh cycle (enable the pref). r=smaug.

And I confirmed that setting dom.event.coalesce_mouse_move = false fixes the issue on Nightly75.0a1 Windows10.
So, Stylo exposed the existing issue.

Component: CSS Transitions and Animations → DOM: Events
Regressed by: 1392876
No longer regressed by: stylo-nightly

There's something fishy in that reduced test case. I'm not sure why we're getting transitions at all. CSS animations shouldn't trigger transitions (and stylo should have fixed that). So maybe there is some bad interaction with the coalesced mouse move events.

Unrelated, but the reduced test case has:

a {
  color: black
  transition: color .3s ease-in-out;
	-moz-transition: color .3s ease-in-out;
  -webkit-text-decoration-skip: ink;

But the first line is missing a ; so the color and the transition declarations there are broken and only the -moz-transition declaration applies.

Flags: needinfo?(brian)

(In reply to Emilio Cobos Álvarez (:emilio) from comment #3)

I think Firefox is right on this one, note that there's both a transition and an animation. Removing the any of both makes it work as expected.

Specifically it's fine to have both transitions and animations running, but it looks like the transition is being triggered here by the end of the CSS animation but that should never happen.

Attached file corrected_rediced.html

I got same regression window of comment#4 with corrected_rediced.html. And dom.event.coalesce_mouse_move = false also fix the issue.

Component: DOM: Events → CSS Transitions and Animations

My best guess at this point is there's something in our transitions/style machinery that doesn't handle FlushType::Event added in bug 1361067 (and enabled in bug 1392876).

Perhaps we think style has been updated when it hasn't, or vice versa, and fail to ignore the change from the end of the CSS animations.

Or perhaps when we go to flush the CSS animation styles we end up flushing the to-be-coalesced mouse events and detecting style changes even though they are only due to the CSS animation finishing?

The priority flag is not set for this bug.
:emilio, could you have a look please?

For more information, please visit auto_nag documentation.

Flags: needinfo?(emilio)
Flags: needinfo?(emilio)
Priority: -- → P3
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.