Closed
Bug 1424846
Opened 7 years ago
Closed 6 years ago
hiding elements with CSS transition animation leaves random artifacts
Categories
(Core :: Web Painting, defect)
Tracking
()
RESOLVED
DUPLICATE
of bug 1423528
People
(Reporter: hendel.tom, Unassigned)
References
Details
(Keywords: regression)
Attachments
(3 files)
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 :-)
Reporter | ||
Comment 1•7 years ago
|
||
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
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?
Status: UNCONFIRMED → NEW
status-firefox57:
--- → affected
status-firefox58:
--- → affected
status-firefox59:
--- → affected
Component: General → Layout: Web Painting
Ever confirmed: true
Flags: needinfo?(matt.woodrow)
Keywords: regression
Product: Firefox → Core
Updated•7 years ago
|
Updated•6 years ago
|
Status: NEW → RESOLVED
Closed: 6 years ago
Flags: needinfo?(matt.woodrow)
Resolution: --- → DUPLICATE
Fixed in 59 in the duplicate.
You need to log in
before you can comment on or make changes to this bug.
Description
•