1311613 - Evolution asked : Console CSS error should display the rejected value

Status: NEW

(DevTools :: Console, enhancement, P3)

Description

[guillaume.kerampran]

User Agent: Mozilla/5.0 (Windows NT 6.3; Win64; x64; rv:49.0) Gecko/20100101 Firefox/49.0
Build ID: 20160922113459

Steps to reproduce:

In Firefow Developper Edition
When a css rule is wrong either in a css file or while setting it in javascript (Ex : .myClass {length:10;} or myDiv.style.length = 10;)



Actual results:

In the css console I have a message "Erreur d’analyse de la valeur pour « height ».  Déclaration abandonnée."


Expected results:

It would be great to complete the message to have
"Erreur d’analyse de la valeur pour « height ».  Déclaration abandonnée. Valeur analysée : height:10;"

This way is faster than clicking on the link on the left to go in the css page. And when it is due to javascript setting, i don't always find the code (sometimes I've got a blank page)

Comment 1

[Nicolas Chevobbe [:nchevobbe]]

Karl, would that be something useful for the webcompat team?

Comment 2

[Karl Dubost💡 :karlcow]

ok checking on a real site.

16:25:52.026 Error in parsing value for ‘border’. Declaration dropped. mobile.css:2625:20

clicking on the link and getting

.mm_059 .cell {  
  display: table-cell; 
  width: 50%;
  padding: 8px 0;  
  border: 1px solid.mm_059 .cover; 
}

Usually I deactivate CSS in the console, because it is too noisy.
I guess for your own site it's practical if there's not that many errors.
I guess there are different type of mistakes and they do not have the same value.

For example, these rules

.foo {
  display: -webkit-box;
  display: -webkit-flex;
  display: -ms-flexbox;
  display: flex;
}

will create something like

16:25:52.037 Error in parsing value for ‘display’.  Declaration dropped. mobile_base.css:348:12

These are less useful, because at least one of them is valid and it's (was) often necessary for webcompat reason. It would be interesting to silence these. (warning category)

But if we take something like:

width: pink;

Surfacing them as errors with the value.

In the JS case it could be indeed useful to have the original JS context. Probably super hard to do.

Summary:

• Less noisy would be good
• Surfacing wrong values could be useful (if less noisy)
• better console to JS would be good.

BUT from webcompat side, our main issue is that often people use a property which is missing for Firefox.

Example:

.foo {
   zoom: 1
}

or

::-webkit-input-placeholder { 
  color: pink;
}

and we detect these in two ways:

1. Inspector looking at the CSS properties, trying to find which CSS file this is defined
   then going to the file in the Style Editor and try to find what could be defined for this selector.
   (painful, aka we don't have access to invalid properties)
2. Using the Chrome devtools and compare the differences in the inspector (sometimes easier).

So for webcompat team the proposal as made up there is not that useful, specifically if super noisy logs.

Comment 3

[Jan Honza Odvarko [:Honza] (always need-info? me)]

Great feedback Karl!

Less noisy would be good

Perhaps grouping CSS Warnings could help to make the Console less noisy. We could use various criteria (e.g. grouping warnings/errors, by URL, by CSS selector, etc.)

In the JS case it could be indeed useful to have the original JS context. Probably super hard to do.

I really like this idea!

Honza

Comment 4

[Jan Honza Odvarko [:Honza] (always need-info? me)]

@Sean: Is it possible to get JS context (line number/file url) of the place which caused CSS warning/error by setting wrong CSS prop value?

You might also seecomment #2
Or is there anyone else I could ask?

Thanks!
Honza

Comment 5

[Sean Voisen (:svoisen)]

@Sean: Is it possible to get JS context (line number/file url) of the place which caused CSS warning/error by setting wrong CSS prop value?

@Honza: I think Cameron might be able to answer your question. I actually don't know if we maintain that information or not.

Comment 7

[Cameron McCormack (:heycam)]

I'm not really familiar with how to get that info out of the JSContext, but It's probably possible somehow. Gecko_ReportUnexpectedCSSError would need to do that.