Closed Bug 1550432 Opened 3 years ago Closed 2 years ago

Don't report CSS errors when valid aliases have already been parsed in the same declaration block


(Core :: CSS Parsing and Computation, defect, P3)




Tracking Status
firefox69 --- fixed


(Reporter: emilio, Assigned: violet.bugreport, Mentored)


(Blocks 1 open bug)


(Whiteboard: [layout:backlog:2019q2])


(1 file)

Bug #1538101 fixed the "Multiple declarations for the same property", this is about the other fix.

When a CSS error is reported at parsing time, it eventually ends up in the DevTools web console when it gets opened (and if the right filter is turned on).

In bug 1528426, we're trying to make those errors more actionable for our users. In particular for the WebCompat team to diagnose problems quicker.

One part of this project is to reduce the number of errors displayed, in particular try to remove those that do not appear to be helpful.

Here's the case that we are trying to specifically address in this bug:

div {
  -moz-user-select: none;
  -webkit-user-select: none;
  user-select: none;

In Firefox, the above will lead to an error reported for the user-select property because it isn't a valid Firefox CSS property.
However because both -webkit-user-select and -moz-user-select are valid, the intended feature will still work, and the error will only be perceived as noise to the user.

Hence, the idea to avoid reporting this error at all.

Some conditions that would make this feasible:

  • Only do it when error reporting is on, obviously, to avoid slowing everything down
  • only do this within one declaration block
  • only do this by checking already parsed declarations (no need to parse ahead of the current point)
  • only do this for aliases.

In the use case provided above, it means once the parser reaches user-select, if error reporting mode is on, it would check if valid aliases are already present in the block, would find out that yes, that is the case, and would not report the error.

Suppose that prop is a property that we haven't supported yet, while its -moz-prop
version is already supported.

If an author specifies in a declaration block this property in its standard form
as well as multiple verdor specific forms, as long as -moz-prop is specified, we
shouldn't report error for unknown property prop. Because that's just noise.

Pushed by
Do not report error for unknown property if its known moz prefixed version is specified. r=emilio
Closed: 2 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla69
Assignee: nobody → violet.bugreport
You need to log in before you can comment on or make changes to this bug.