STR: - Go to https://paul.cx/photos - Mouse hover over the images Expected: - The blur and brightness filters are transitioning Actual: - No transition occur, the filter immediately jumps to the end value Worked on a 2015-12-20 Nightly, broken on today's Nightly.

[Tracking Requested - why for this release]: Pushlog: https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=31edd1840c5f651b5dbf182fdb7f04fe98c88d86&tochange=9fbf850dc78d7197132a298f9ec0270c7de16a13 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; https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=530c5bc61a02d1045101a7fdd91cc234e7ba558d&tochange=a23e9cbf415d7dfe54ad6ad687a90492ac039796 Regressed by: e44fb274be90 L. David Baron — Bug 837211 - Add -webkit prefixed aliases for various CSS properties, behind an off-by-default preference. r=bzbarsky

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.

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.

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); http://mxr.mozilla.org/mozilla-central/source/layout/style/nsRuleNode.cpp?rev=6c0ccd4c3566#5223 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...

*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: http://mxr.mozilla.org/mozilla-central/source/layout/style/nsCSSPropAliasList.h?rev=1208659f1a97&force=1#185 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. https://www.chromestatus.com/metrics/css/popularity#webkit-filter 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. > https://www.chromestatus.com/metrics/css/popularity#webkit-filter 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.

I verified that this patch fixes the issue with the attached testcase, as well as the original URL from comment 0.

Filed https://github.com/whatwg/compat/issues/25 to make sure this ends up in the Compat spec.

Tracking belatedly since this is a regression, in case it re-opens.

Added a compatibility note for this to https://developer.mozilla.org/en-US/docs/Web/CSS/filter and listed it at https://developer.mozilla.org/en-US/Firefox/Releases/46#CSS. Daniel, can you please verify those changes? Sebastian

The changes look good. Thanks!