New issue
Advanced search Search tips
Note: Color blocks (like █ or █) mean that a user may not be available. Tooltip shows the reason.

Issue 811042 link

Starred by 4 users
Status: Duplicate
Merged: issue 618142
Owner: ----
Closed: Feb 2018
Cc:
█ sindhu.chelamcherla@chromium.org
Components:
EstimatedDays: ----
NextAction: ----
OS: Linux , Windows , Mac
Pri: 2
Type: Compat



Sign in to add a comment

Combination of CSS Variables, <use> tag and animations causes a rendering (caching?) bug with inline SVG

Reported by dennis.f...@gmail.com, Feb 10 2018 
UserAgent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/64.0.3282.143 Safari/537.36 Vivaldi/1.95.1077.45

Example URL:
https://codepen.io/darkwiiplayer/pen/MQpqvy

Steps to reproduce the problem:
1. Create an animated inline SVG with some of its components using a CSS variable for the fill attribute
2. Create two copies of the animation using the <use> tag
3. Set the CSS variable in the second one to change the fill color

What is the expected behavior?
The animation to the left should be all purple and the one to the right should be all blue.

What went wrong?
The animated parts in the first animation have the same color as in the second animation, even though they shouldn't

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: 64.0.3282.143  Channel: n/a
OS Version: 
Flash Version: 

Looks to me like a problem with animation caching :)

Comment 1 by dennis.f...@gmail.com, Feb 10 2018 

Ah, I forgot to mention this, but I reproduced this bug: In chrome in windows, Vivaldi *1.14.1077.45 (Stable channel) (64-bit)* on linux and *64.0.3282.119 (Official Build) Built on Ubuntu , running on LinuxMint 18.3 (64-bit)*

I also made sure that it actually renders properly on firefox (58.0.1 quantum)

Comment 2 by yannic.b...@gmail.com, Feb 10 2018

Components: Internals>Compositing>Animation Blink>CSS
Labels: OS-Mac OS-Windows
Status: Untriaged (was: Unconfirmed)
Thanks for reporting this!
Also reproducible on Mac 64.0.3282.140 and 66.0.3344.0.

Comment 3 by nainar@chromium.org, Feb 12 2018

Labels: Hotlist-Interop
Status: Available (was: Untriaged)

Comment 4 by f...@opera.com, Feb 12 2018 

This looks like it could be another dupe of issue 618142.

Comment 5 by manoranj...@chromium.org, Feb 12 2018

Labels: Needs-Bisect Needs-Triage-M64

Comment 6 by dennis.f...@gmail.com, Feb 13 2018 

Indeed it seems like a very similar bug, though in my example the first object takes the color of the second, while in issue 618142 it's the other way around for some reason.

Comment 7 by sindhu.chelamcherla@chromium.org, Feb 13 2018

Cc: sindhu.chelamcherla@chromium.org
Labels: -Needs-Bisect Triaged-ET M-66 FoundIn-66 Target-66
Able to reproduce this issue on stable 64.0.3282.140, beta 65.0.3325.51, latest canary 66.0.3345.0 using Windows 10, Mac 10.13.3, Ubuntu 14.04 with codepen given in comment#0. i.e; Both animations have blue color.

This issue is seen from M-60. Hence considering this issue as Non-Regression and removing Needs-Bisect label.

Comment 8 by futhark@chromium.org, Feb 26 2018

Components: -Blink>CSS -Internals>Compositing>Animation Blink>SVG
Moving to Blink>SVG to get an evaluation of wether it's a duplicate of issue 618142.

Comment 9 by f...@opera.com, Feb 26 2018

Mergedinto: 618142
Status: Duplicate (was: Available)
The DCHECK in ElementAnimations::UpdateBaseComputedStyle triggers, so it does look like different elements fighting over/corrupting state (in this case the base computed style, while in issue 618142 it has been a variety of other animation-related state.) I think that's proof enough that it is a duplicate. Need to verify after fix though.
►

Sign in to add a comment