807336 - "Unknown property" parse warnings appear in error console, for unrecognized properties in a failing @supports condition

Status: RESOLVED FIXED

(Core :: CSS Parsing and Computation, defect)

Description

[Daniel Holbert [:dholbert]]

Attachment: testcase 1

I'm attaching a testcase, with this style:
>      @supports (display: pirate) {
>        #myDiv {
>          parrot: red;
>          leg: peg;
>          eyepatch: visible;
>        }
>      }

Of course "display: pirate" is unsupported, so the question is -- how do we deal with the also-unsupported properties in the @supports condition?  I'd expect that we wouldn't report parse errors for them, because they're in an @supports rule for some unsupported feature, so conceptually they're "skipped" and likely known-to-be-not-supported.

Formal STR below.

STR:
 0. Open error console.  Clear it if you like, to make it easier to see things.
 1. Load testcase.
 2. Inspect error console.

EXPECTED RESULTS: No CSS errors/warnings reported.

ACTUAL RESULTS:  CSS parsing errors are reported.

Comment 1

[Daniel Holbert [:dholbert]]

BTW: I filed bug 798592 on a situation like this, on the assumption that this sort of thing would produce EXPECTED RESULTS & prevent error-console spam.  Maybe I was just mistaken about that, though...

Comment 2

[Cameron McCormack (:heycam)]

I agree, I think parsing errors should only be reported for non-value related errors (like missing parens).

Comment 3

[Cameron McCormack (:heycam)]

Sorry, I read comment 0 too quickly so my comment 2 is wrong.  What I should have said is that property related parse errors (bad property name or value) should be suppressed inside failing @supports rules.  So things like a missing ":" in a declaration or an unexpected EOF would still get reported.

Comment 4

[Cameron McCormack (:heycam)]

What about when we parse a declaration because of, say, assigning to cssText somewhere inside an existing failing @supports rule?  Should we be searching up the tree to find if we should be suppressing the errors here?

Comment 5

[Cameron McCormack (:heycam)]

Attachment: patch

Comment 6

[aja+bugzilla]

A design choice to consider: making these Info messages instead.
Something like:
 
 Info: line/col value foo for property bar in @supports rule is/is not supported.

may be more author-friendly.

Comment 7

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

Comment on attachment 678606 [details] [diff] [review]
patch

I was originally thinking you were going to hook into OUTPUT_ERROR/CLEAR_ERROR, but after looking at this for a bit I think this is fine.

r=dbaron

Comment 8

[Cameron McCormack (:heycam)]

https://hg.mozilla.org/integration/mozilla-inbound/rev/a1864cbae86c

Comment 9

[Ryan VanderMeulen [:RyanVM]]

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