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

RESOLVED FIXED in Firefox 46

Status

()

RESOLVED FIXED
3 years ago
3 years ago

People

(Reporter: padenot, Assigned: dholbert)

Tracking

(Blocks: 1 bug, {dev-doc-complete, regression})

Trunk
mozilla46
dev-doc-complete, regression
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(firefox45 unaffected, firefox46+ fixed)

Details

Attachments

(2 attachments)

(Reporter)

Description

3 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.
(Reporter)

Updated

3 years ago
Keywords: regression, regressionwindow-wanted
(Reporter)

Updated

3 years ago
Summary: CSS transition of a filter don't work anymore → CSS transition of a filter does not work anymore

Comment 1

3 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
Blocks: 1213126
status-firefox45: --- → unaffected
status-firefox46: --- → affected
tracking-firefox46: --- → ?

Comment 2

3 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
Blocks: 837211
Component: Graphics → CSS Parsing and Computation
Flags: needinfo?(dbaron)
Keywords: regressionwindow-wanted
(Assignee)

Comment 3

3 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.
Flags: needinfo?(dholbert)
(Assignee)

Updated

3 years ago
Flags: needinfo?(dholbert)
Summary: CSS transition of a filter does not work anymore → CSS transition of "-webkit-filter" does not work
(Assignee)

Updated

3 years ago
Flags: needinfo?(dholbert)
(Reporter)

Comment 4

3 years ago
Created attachment 8703687 [details]
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)
(Assignee)

Comment 7

3 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.
(Assignee)

Comment 8

3 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...
Flags: needinfo?(dholbert)
(Assignee)

Comment 9

3 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.
(Assignee)

Comment 10

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

Comment 11

3 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.
Assignee: nobody → dholbert
Blocks: 1170789
Version: 45 Branch → Trunk
(Assignee)

Updated

3 years ago
Attachment #8703687 - Attachment filename: file_1236506.txt → file_1236506.html
Attachment #8703687 - Attachment mime type: text/plain → text/html
(Assignee)

Updated

3 years ago
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)
(Assignee)

Comment 12

3 years ago
Created attachment 8704797 [details] [diff] [review]
fix v1
Attachment #8704797 - Flags: review?(cam)
(Assignee)

Comment 13

3 years ago
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+

Comment 15

3 years ago
bugherder
https://hg.mozilla.org/mozilla-central/rev/200aa49f81d2
Status: NEW → RESOLVED
Last Resolved: 3 years ago
status-firefox46: affected → fixed
Resolution: --- → FIXED
Target Milestone: --- → mozilla46
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.
tracking-firefox46: ? → +
(Assignee)

Updated

3 years ago
Blocks: 1259345
Depends on: 1275069
Keywords: dev-doc-needed
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
Flags: needinfo?(dholbert)
(Assignee)

Comment 19

3 years ago
The changes look good. Thanks!
Flags: needinfo?(dholbert)
Keywords: dev-doc-needed → dev-doc-complete
You need to log in before you can comment on or make changes to this bug.