Closed Bug 1236506 Opened 9 years ago Closed 9 years ago

CSS transition of "-webkit-filter" does not work (i.e. add support for "-webkit-filter" alias)


(Core :: CSS Parsing and Computation, defect)

Not set



Tracking Status
firefox45 --- unaffected
firefox46 + fixed


(Reporter: padenot, Assigned: dholbert)


(Blocks 1 open bug)


(Keywords: dev-doc-complete, regression)


(2 files)

- Go to
- Mouse hover over the images

- The blur and brightness filters are transitioning

- No transition occur, the filter immediately jumps to the end value

Worked on a 2015-12-20 Nightly, broken on today's Nightly.
Summary: CSS transition of a filter don't work anymore → CSS transition of a filter does not work anymore
[Tracking Requested - why for this release]:


Triggered by: 9fbf850dc78d	Daniel Holbert — Bug 1213126: Enable support for webkit-prefixed CSS properties & features by default. r=heycam
Pushlog with enabled layout.css.prefixes.webkit = true;

Regressed by:
e44fb274be90	L. David Baron — Bug 837211 - Add -webkit prefixed aliases for various CSS properties, behind an off-by-default preference. r=bzbarsky
Blocks: 837211
Component: Graphics → CSS Parsing and Computation
Flags: needinfo?(dbaron)
From playing around briefly with devtools, the site has:
  transition: filter 0.3s;
  -webkit-transition: -webkit-filter 0.3s;

That second line seems to be parsed successfully but ineffective at actually transitioning. It works if I replace that line with the following, though:
  -webkit-transition: filter 0.3s;

So "-webkit-transition" seems to be OK.  But "-webkit-filter" in the transition *value* doesn't work properly.
Flags: needinfo?(dholbert)
Flags: needinfo?(dholbert)
Summary: CSS transition of a filter does not work anymore → CSS transition of "-webkit-filter" does not work
Flags: needinfo?(dholbert)
Attached file Minimal test-case
On this reduced test-case, Firefox Nightly transitions the first two <div>, Chrome only the last one (but style is applied on hover on the second one).
I don't see anything in either nsRuleNode::ComputeDisplayData or nsTransitionManager::StyleContextChanged that resolves aliases that are specified in transition-property, although it's not clear to me whether they end up being treated as an unknown property or causing assertions.
Flags: needinfo?(dbaron)
Er, maybe the nsRuleNode code probably does convert them, but bug 784461 requires changing that.
Right now we punt on the prefixed property-name here:
> 5215       if (val.GetUnit() == eCSSUnit_Ident) {
> 5218         nsCSSProperty prop =
> 5219           nsCSSProps::LookupProperty(propertyStr,
> 5220                                      nsCSSProps::eEnabledForAllContent);
> 5221         if (prop == eCSSProperty_UNKNOWN ||
> 5222             prop == eCSSPropertyExtra_variable) {
> 5223           transition->SetUnknownProperty(prop, propertyStr);

SetUnknownProperty just sets transition->mProperty = eCSSProperty_UNKNOWN, and transition->mUnknownProperty to the nsIAtom for "-webkit-filter".

I assume the transition doesn't usefully work from that point on (due to having UNKNOWN in mProperty), though I'm not sure.
So nsCSSProps::LookupProperty there is returning eCSSProperty_UNKNOWN, before it gets to its alias-handling code at the end. That seems like a bug. Poking around to see if I can figure out what's going wrong...
Flags: needinfo?(dholbert)
*facepalm* Can't believe I didn't check this already, but the problem is simply that we don't support "-webkit-filter", at all -- i.e. it's not listed here:

So we're parsing "-webkit-transition" with a completely-unknown <ident> as the property name.

The obvious fix is to just add an alias -webkit-filter, I guess. says it's got nearly 17% usage, so it makes sense to add it.
(This bug reveals an interesting quirk about adding -webkit prefix support.

Hypothetically, we might think we don't need to alias "-webkit-filter" (or another similar property) because it's modern enough that authors tend to specify the unprefixed version alongside it. BUT, if there's any chance that authors will use such a property in a transition or animation, then we really do need an alias -- even with authors providing fallback -- in case authors specify the fallback in the wrong order. (as is the case in comment 3)
(In reply to Daniel Holbert [:dholbert] from comment #9)
> The obvious fix is to just add an alias -webkit-filter, I guess.
> says it's
> got nearly 17% usage, so it makes sense to add it.

MS Edge implements it, too, according to the doc linked from bug 1213126 comment 0. (which includes an entry for  "webkitFilter")

Anyway -- taking.
Assignee: nobody → dholbert
Blocks: 1170789
Version: 45 Branch → Trunk
Attachment #8703687 - Attachment filename: file_1236506.txt → file_1236506.html
Attachment #8703687 - Attachment mime type: text/plain → text/html
Summary: CSS transition of "-webkit-filter" does not work → CSS transition of "-webkit-filter" does not work (i.e. add support for "-webkit-filter" alias)
Attached patch fix v1Splinter Review
Attachment #8704797 - Flags: review?(cam)
I verified that this patch fixes the issue with the attached testcase, as well as the original URL from comment 0.
Attachment #8704797 - Flags: review?(cam) → review+
Closed: 9 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla46
Filed to make sure this ends up in the Compat spec.
Tracking belatedly since this is a regression, in case it re-opens.
Blocks: 1259345
Depends on: 1275069
Added a compatibility note for this to and listed it at

Daniel, can you please verify those changes?

Flags: needinfo?(dholbert)
The changes look good. Thanks!
Flags: needinfo?(dholbert)
You need to log in before you can comment on or make changes to this bug.