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

Issue 486195 link

Starred by 4 users

Issue metadata

Status: WontFix
Last visit > 30 days ago
Closed: May 2015
EstimatedDays: ----
NextAction: ----
OS: ----
Pri: 2
Type: Bug-Regression

Sign in to add a comment

Ability to CSS animate <progress> pseudo elements regressed

Reported by, May 8 2015

Issue description

Chrome Version       : 42.0.2311.135
URLs (if applicable) :
Other browsers tested:
Add OK or FAIL after other browsers where you have tested this issue:
     Safari 8: OK

What steps will reproduce the problem?
1. Go to
2. See the <progress> is a green bar
3. Observe there is no red bar animating back and forth

What is the expected result?
A red bar is visible animating back and forth within the <progress> element.

What happens instead?
No red bar is displayed.

Please provide any additional information below. Attach a screenshot if

WinJS applies a custom CSS animation to -webkit-progress-value for an indeterminate progress bar. In recent versions of Chrome this functionality has been regressed and the animation isn't displayed. 

Comment 1 by, May 18 2015

Labels: Needs-Bisect Cr-Blink-Animation Cr-Blink-HTML Cr-Blink-HTML-Progress
Labels: -Type-Bug -Needs-Bisect Type-Bug-Regression Cr-Blink-CSS
Status: Assigned
You are probably looking for a change made after 309810 (known good), but no later than 309811 (first known bad).
NOTE: There is a Blink roll in the range, you might also want to do a Blink bisect.

Blink Roll ->

Just one change:

"CSSAnimations should not use ScopedStyleResolver" -> kochi

Comment 3 by, May 22 2015

Status: Started
Tentative fix uploaded:

I am not sure this is an expected behavior.
Help from CSS animation spec experts needed.

If @keyframes rule is strictly scoped, progress::-webkit-progress-value and
@keyframes progress should not match, as the progress::-webkit-progress-value
is not in the same treescope.  But the fact that the progress is actually a
user agent shadow is an implementation detail of Blink, so to match Safari's
behavior, I think the fix is a reasonable compromise.

Comment 4 by, May 25 2015

Status: WontFix
Closing this as WontFix.

Reason: @keyframes rule name is scoped, so the name specified is only available
in the same treescope (i.e. in the same document or shadow root).
progress::-webkit-progress-value pierces document-UA shadow root boundary
and styles the element, but animation name defined in the document treescope
isn't available in UA shadow root, thus the animation doesn't apply.

This breaks compatibility with Safari/WebKit, but in general, -webkit-
is only available for WebKit/Blink-based browsers and not interoperable
among all browsers, and thus the usage is discouraged.

A workaround could be to make your own widget and animate it, which should
work all (if CSS animation is implemented) browsers.

Sign in to add a comment