New issue
Advanced search Search tips

Issue 841660 link

Starred by 2 users

Issue metadata

Status: Available
Owner: ----
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Linux , Windows , Mac
Pri: 2
Type: Bug



Sign in to add a comment

Nested animations with filter:opacity(x) and animation-fill-mode:both don't work properly

Reported by bensapi...@gmail.com, May 10 2018

Issue description

UserAgent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_13_4) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/68.0.3422.0 Safari/537.36

Example URL:
https://output.jsbin.com/veyipudodo

Steps to reproduce the problem:
1. Make nested animations including filter as exemplified in JSBin example.
2. Load page.
3. Watch fail.

What is the expected behavior?
As animation-fill-mode is set, the element (loader-spinner thingy) should keep its state as of the last animated frame. This is how I expect it to work and how it works on Safari and Firefox

What went wrong?
Instead, the element jumps back to what appears to be its first animated frame.

Does it occur on multiple sites: N/A

Is it a problem with a plugin? No 

Did this work before? N/A 

Does this work in other browsers? Yes

Chrome version: 68.0.3422.0  Channel: n/a
OS Version: OS X 10.13.4
Flash Version: 

When animation-fill-mode is set to "forwards" rather than "both", behavior is even weirder. The element, rather than just blinking out upon completion, appears to blink in and out multiple times quite erratically. 

Furthermore, this appears to also occur with the brightness filter, though I haven't tested any others.

Finally, on JSBin the element "snaps" back to the opacity that it should be when the mouse enters into or is moved in the viewport, although this doesn't happen in a "native" implementation.
 
onFirefox.mov
390 KB View Download
onSafari.mov
747 KB View Download
onChrome.mov
1.6 MB View Download
onChromium.mov
2.4 MB View Download
Components: Blink>Animation
Cc: smcgruer@chromium.org
Labels: -Type-Compat Needs-Bisect OS-Linux OS-Windows Type-Bug
Status: Untriaged (was: Unconfirmed)
Thanks for the detailed report and test case.

I can confirm this is happening on latest stable (66.0.3359.139) and Canary (68.0.3427.0).

It appears that the after the opacity animation is finished for a short period it does not hold its value which it should according to its fill. This issue does not happen if one removes the rotation animation.

Adding Needs-Bisect to see if this is a regression.




Labels: -Needs-Bisect Triaged-ET Needs-Triage-M68 M-68 FoundIn-68 Target-68
Able to reproduce the issue on Mac 10.13.3, Win-10 and Ubuntu 14.04 using latest canary #68.0.3426.0.
This is a non-regression issue as it is observed from M60 old builds. 
Attaching screen cast for reference.

Hence, marking it as untriaged to get more inputs from dev team.

Thanks...!!
841660.mp4
1.1 MB View Download

Comment 4 by yigu@chromium.org, May 11 2018

Owner: flackr@chromium.org
Status: Assigned (was: Untriaged)

Comment 5 by yigu@chromium.org, May 11 2018

Labels: -Needs-Triage-M68
Labels: Hotlist-Polish
Cc: flackr@chromium.org
Owner: ----
Status: Available (was: Assigned)
Afaik, flackr@ is not currently looking at this bug. Moving to Available so that people can pick it up if they have cycles.

Sign in to add a comment