Thomas Hendel Reporter
	Description • 7 years ago

We have a wep-app that uses a CSS animation as "busy" indicator (a.k.a. "hourglass cursor").
It consists of a top-level DIV that covers the entire body (called "block screen").
This "block screen" contins a centered DIV with a fixed size, and within that centered DIV are three smaller DIVs that have a CSS transition animation - I attached a simple example that.
When the application becomes busy, then it shows the "block screen" DIV (display:flex) so that the user sees the animation. When the application is able again to accept input, then it hides the "block screen" (display:none).
And in that case some random artifacts of the animated elements ramain visible, look like "animation garbage".
Actually, only Firefox shows this "garbage" if the "block screen" is hidden - Chromium based browsers and Microsoft's browsers hide everything as expected.
You can seen a live example here:
https://www.pyro-man.de/test/ani/anitest.html
(that's exactly the source of the attached ZIP file)

In fact, there is an ugly workaround: If I do not use CSS classes but change elements style in JS code AND defer the hiding of the top level "block screen" DIV (after the animated elements where changed) using setTimeout with 15...20 ms timeout, then everything disappears. But setTimeout is ugly end evil :-)

	Thomas Hendel Reporter
	Comment 2 • 7 years ago

this is just one example that shows the remaining artifacts after the animation has been hidden; in most cases only the green square leaves remaining artifacts, but I could not see any systematic behavior

	Cosmin Muntean [:cmuntean], Ecosystem QA (PTO until September 8th)
	Comment 3 • 7 years ago

User Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:57.0) Gecko/20100101 Firefox/57.0
Firefox: 57.0.2, Build ID: 20171206182557

I have managed to reproduce this issue using the "https://www.pyro-man.de/test/ani/anitest.html" website on latest Firefox (57.0.2) release and latest Nightly (59.0a1) build. The issue is not reproducible on Firefox 55

Considering this I have performed a regression range using the mozregression tools. Here are the results:

Last good revision: 958d2a5d10091401fd5e900e8e063d21940c137e
First bad revision: 7f894f791cdf170d788507d0eff30024ce699523
INFO: Pushlog: https://goo.gl/J418oJ

It seems that this issue is not reproducible on Mac or Linux.
From the provided pushlog I suspect Bug 1361970. Matt, can you please look over the pushlog and see if anything stands out?

	Liz Henry (:lizzard Please n-i to RyanVM, jcristau, or pascal)
	Comment 5 • 6 years ago

Fixed in 59 in the duplicate.