1067634 - CSS Warning in browser console:"Unknown property 'will-change'. Declaration dropped. full-screen-override.css:24"

Status: RESOLVED FIXED

(Core :: CSS Parsing and Computation, defect)

Description

[Daniel Holbert [:dholbert]]

STR:
 1. Start up Firefox. (Fresh profile, ideally.)
 2. Ctrl+Shift+J to open browser console
 3. Click dropdown for CSS and click to enable "Warnings".

ACTUAL RESULTS:
The following entry appears:
{
Unknown property 'will-change'.  Declaration dropped. full-screen-override.css:24
}



This pref is not currently enabled by default, as shown here:
http://mxr.mozilla.org/mozilla-central/source/modules/libpref/init/all.js?rev=efb085f286fd#1985

So, we complain about failing to parse it, when we parse this UA stylesheet.
We can suppress the warning by wrapping this particular declaration in a @supports rule.

Comment 1

[Daniel Holbert [:dholbert]]

Attachment: fix v1

Comment 2

[Cameron McCormack (:heycam)]

We don't have any mechanism at the moment to invalidate @supports rules when a pref changes that would cause the expression to evaluate differently.  If you load a document with the pref on, then flip it off and restyle things, then you're going to start getting the warnings again.

Comment 3

[Cameron McCormack (:heycam)]

For the moment let's take this patch, so that we avoid the ugly warnings web developers will see by default.  But we should somehow make @supports rules re-evaluable when relevant prefs change.  File a followup for that?

Comment 4

[Daniel Holbert [:dholbert]]

(In reply to Cameron McCormack (:heycam) from comment #2)
> If
> you load a document with the pref on, then flip it off and restyle things,
> then you're going to start getting the warnings again.

I don't think we'll get more warnings -- I think we only parse this stylesheet once, at startup.  Since we don't re-parse it after that, we don't re-spam-warnings after that.

This means (as you suggest) that we don't quite handle dynamic enabling of CSS prefs, when the prefs are used in a UA stylesheet, because we'll already be locked into not-honoring-that-rule. (regardless of whether it's wrapped in a @supports condition)

I'll file a followup on figuring out a strategy to address this.

Comment 5

[Daniel Holbert [:dholbert]]

(In reply to Cameron McCormack (:heycam) from comment #3)
> But we should somehow make @supports rules re-evaluable when relevant prefs change.

(To emphasize: the presence of @supports guards is orthogonal to the issue that you're describing. Even without a @supports guard, we'll fail to parse style for disabled properties in UA stylesheets at startup, and we'll never get a chance to re-parse it successfully if the pref is dynamically enabled later on.)

Comment 6

[Cameron McCormack (:heycam)]

Indeed you're right, we'll only parse this once and get the warning once.

(In reply to Daniel Holbert [:dholbert] from comment #5)
> (To emphasize: the presence of @supports guards is orthogonal to the issue
> that you're describing. Even without a @supports guard, we'll fail to parse
> style for disabled properties in UA stylesheets at startup, and we'll never
> get a chance to re-parse it successfully if the pref is dynamically enabled
> later on.)

Yes good point.

Comment 7

[Daniel Holbert [:dholbert]]

Anyway -- I filed bug 1068477 with some more thoughts about this. Thanks for the review!

Comment 8

[Daniel Holbert [:dholbert]]

Landed: https://hg.mozilla.org/integration/mozilla-inbound/rev/c62eaab73c38

Comment 9

[Ryan VanderMeulen (PTO, back July 27)]

https://hg.mozilla.org/mozilla-central/rev/c62eaab73c38