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

Status: RESOLVED FIXED

(Core :: CSS Parsing and Computation, defect)

Description

[Paul Adenot (:padenot)]

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.

Comment 1

[Alice0775 White]

[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

Comment 2

[Alice0775 White]

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

Comment 3

[Daniel Holbert [:dholbert]]

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.

Comment 4

[Paul Adenot (:padenot)]

Attachment: 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).

Comment 5

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

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.

Comment 6

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Er, maybe the nsRuleNode code probably does convert them, but bug 784461 requires changing that.

Comment 7

[Daniel Holbert [:dholbert]]

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.

Comment 8

[Daniel Holbert [:dholbert]]

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...

Comment 9

[Daniel Holbert [: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:
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.

Comment 10

[Daniel Holbert [:dholbert]]

(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)

Comment 11

[Daniel Holbert [:dholbert]]

(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.

Comment 12

[Daniel Holbert [:dholbert]]

Attachment: fix v1

Comment 13

[Daniel Holbert [:dholbert]]

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

Comment 14

[Pulsebot]

https://hg.mozilla.org/integration/mozilla-inbound/rev/200aa49f81d2

Comment 15

[Carsten Book [:Tomcat]]

https://hg.mozilla.org/mozilla-central/rev/200aa49f81d2

Comment 16

[Mike Taylor [:miketaylr]]

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

Comment 17

[Liz Henry (:lizzard) (relman/hg->git project)]

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

Comment 18

[Sebastian Zartner [:sebo]]

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

Comment 19

[Daniel Holbert [:dholbert]]

The changes look good. Thanks!