devtools console shows inaccurate source code in error message when parsing some CSS hacks (like \9)

RESOLVED WORKSFORME

Status

()

Firefox
Developer Tools: Console
RESOLVED WORKSFORME
2 years ago
23 days ago

People

(Reporter: Chris Rebert, Unassigned)

Tracking

Trunk
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

(Reporter)

Description

2 years ago
Created attachment 8658985 [details]
Screenshot of incorrect error message

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_10_5) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/45.0.2454.85 Safari/537.36

Steps to reproduce:

1. Open the DevTools' Web Console
2. Enable "Errors" and "Warnings" in the "CSS" dropdown menu
3. Visit http://getbootstrap.com/javascript/ or any other webpage using Bootstrap v3.3.5's minified CSS (https://github.com/twbs/bootstrap/blob/v3.3.5/dist/css/bootstrap.min.css )


Actual results:

The console reports the following CSS parsing error:
[[
Expected color but found '#\30 00\9 '.  Error in parsing value for 'background-color'.  Declaration dropped. bootstrap.min.css:5:117004
]]
(See screenshot)


Expected results:

The parsing error message should instead read something like:
[[
Expected color but found '#000\9'.  Error in parsing value for 'background-color'.  Declaration dropped. bootstrap.min.css:5:117004
]]

The source code snippet in Firefox's error message is inaccurate and does not match the actual CSS code.
The portion of the minified CSS referenced in the error message (circa line 5 column 117004) actually reads "background-color:#000\9;", NOT "background-color:#\30 00\9 ;".
The "\30" and extra spaces in the code snippet shown in the error message don't match the actual code, which is very confusing to developers trying to interpret the error message.
(Reporter)

Comment 1

2 years ago
Original Bootstrap bug report: https://github.com/twbs/bootstrap/issues/17546

Updated

2 years ago
Component: Untriaged → Developer Tools: Console

Comment 2

2 years ago
The parser fails to display correctly some CSS hacks for IE, like "#000\9", see bug 787981.

http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=9a6d708faf3f&tochange=b959971b8219
Before:
Expected color but found '#000	'.
After:
Expected color but found '#\30 00\9 '.
Blocks: 787981
Flags: needinfo?(mihai.sucan)
OS: Unspecified → All
Hardware: Unspecified → All
Summary: devtools console shows inaccurate source code in CSS parse error message → devtools console shows inaccurate source code in error message when parsing some CSS hacks (like \9)

Comment 3

2 years ago
Inside that changeset from comment#2 is http://hg.mozilla.org/mozilla-central/rev/b11550b854e8

bug#229827  escape unprintable characters in CSS parser diagnostics. r=dbaron 

When you link Bug#787981 do you know that is the cause, or just that the problem was introduced in that changeset ?

Also how did you bisect back to 2012 so fast? kudos to you :)

Comment 4

2 years ago
Missed that bug, anyway, even before 2012-11, the parsing is wrong, it should display \9.
Blocks: 229827
No longer blocks: 787981
Flags: needinfo?(mihai.sucan) → needinfo?(zackw)
The '\30 ' is happening because the diagnostic printer (specifically, nsCSSToken::AppendToString) doesn't bother distinguishing eCSSToken_ID and eCSSToken_Ref -- the only difference between them is that one can have an unescaped digit as the first character after the '#' and one can't.  (I don't remember off the top of my head which is which.)  That will be easy to fix.

The '\9' is necessary (do I understand correctly that it appears in the code?)  The space after the '\9' will be hard to get rid of, since the logic that prints these messages does not have access to the original source text and does not know what will be printed *after* the escape.  I might be able to kludge in a correction for escapes at the very end of the token being printed, but I'll have to convince myself it's always safe.

Anyway, I can find time to write the code change to fix this, but I can *not* find time to minimize a test case.  I need one of you to do that.  Please give me something that can be dropped directly into the test suite.  There are similar tests somewhere in layout/style mochitests and dbaron will be happier if you reuse existing infrastructure ;-)
Flags: needinfo?(zackw)
(Reporter)

Updated

2 years ago
Version: 42 Branch → Trunk
(Reporter)

Updated

2 years ago
Status: UNCONFIRMED → NEW
Ever confirmed: true

Comment 6

4 months ago
It would be interesting to see what this prints in a Firefox nightly that has layout.css.servo.enabled set to true.

Comment 7

4 months ago
The output is the same:
Expected color but found ‘#\30 00\9 ’.  Error in parsing value for ‘color’.  Declaration dropped.

http://software.hixie.ch/utilities/js/live-dom-viewer/?%3C!DOCTYPE%20html%3E%0A%3Cstyle%3Ex%7Bcolor%3A%23000%5C9%7D%3C%2Fstyle%3E%20
On the new console frontend, I do see the following : 
`Expected color but found ‘#000\9 ’.  Error in parsing value for ‘background-color’.  Declaration dropped.`
Status: NEW → RESOLVED
Last Resolved: 23 days ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.