Closed Bug 1067634 Opened 6 years ago Closed 6 years ago

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

Categories

(Core :: CSS Parsing and Computation, defect)

defect
Not set
normal

Tracking

()

RESOLVED FIXED
mozilla35

People

(Reporter: dholbert, Assigned: dholbert)

References

Details

Attachments

(1 file)

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.
Attached patch fix v1Splinter Review
Attachment #8489707 - Flags: review?(cam)
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.
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?
Attachment #8489707 - Flags: review?(cam) → review+
(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.
(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.)
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.
Anyway -- I filed bug 1068477 with some more thoughts about this. Thanks for the review!
https://hg.mozilla.org/mozilla-central/rev/c62eaab73c38
Status: ASSIGNED → RESOLVED
Closed: 6 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla35
QA Whiteboard: [good first verify]
Duplicate of this bug: 1106401
You need to log in before you can comment on or make changes to this bug.