Paul Adenot (:padenot) Reporter
	Description • 8 years ago

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.

	Alice0775 White
	Comment 1 • 8 years ago

[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

	Alice0775 White
	Comment 2 • 8 years ago

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

	Daniel Holbert [:dholbert] Assignee
	Comment 3 • 8 years ago

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.

	Paul Adenot (:padenot) Reporter
	Comment 4 • 8 years ago

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

	David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)
	Comment 5 • 8 years ago

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.

	David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)
	Comment 6 • 8 years ago

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

	Daniel Holbert [:dholbert] Assignee
	Comment 7 • 8 years ago

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.

	Daniel Holbert [:dholbert] Assignee
	Comment 8 • 8 years ago

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

	Daniel Holbert [:dholbert] Assignee
	Comment 9 • 8 years ago

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

	Daniel Holbert [:dholbert] Assignee
	Comment 10 • 8 years ago

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

	Daniel Holbert [:dholbert] Assignee
	Comment 11 • 8 years ago

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

	Daniel Holbert [:dholbert] Assignee
	Comment 13 • 8 years ago

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

	Pulsebot
	Comment 14 • 8 years ago

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

	Carsten Book [:Tomcat]
	Comment 15 • 8 years ago
bugherder

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

	Mike Taylor [:miketaylr]
	Comment 16 • 8 years ago

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

	Liz Henry (:lizzard) (relman/hg->git project)
	Comment 17 • 8 years ago

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

	Sebastian Zartner [:sebo]
	Comment 18 • 8 years ago

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

	Daniel Holbert [:dholbert] Assignee
	Comment 19 • 8 years ago

The changes look good. Thanks!