1051900 - css source editor's getInfoAt method sometimes fail

Status: RESOLVED WORKSFORME

(DevTools :: Style Editor, defect)

Description

[Patrick Brosset <:pbro>]

In bug 971702 the 'getInfoAt' method was added to the source editor. It's not used yet anywhere in the devtools and my plan is that start using it for bug 971662.
The goal of this bug is to highlighter nodes that match a given selector when the pointer hovers over selectors in the style-editor panel.

I've found that this function sometimes fail. Take these STR for instance:

- Open the style-editor on this page
- Open the scratchpad
- Switch it to "browser" environment
- Enter and execute the following code:

let editor = [...gDevTools._toolboxes][0][1].getPanel("styleeditor").UI.editors[0].sourceEditor;
editor.getInfoAt({line: 0, ch: 2});

The following exception is fired:

Exception: str is undefined
tokenize@resource://gre/modules/commonjs/toolkit/loader.js -> resource:///modules/devtools/sourceeditor/css-tokenizer.js:129:1
CSSCompleter.prototype.getInfoAt/traverseBackwards@resource://gre/modules/commonjs/toolkit/loader.js -> resource:///modules/devtools/sourceeditor/css-autocompleter.js:1035:22
CSSCompleter.prototype.getInfoAt@resource://gre/modules/commonjs/toolkit/loader.js -> resource:///modules/devtools/sourceeditor/css-autocompleter.js:1079:19
getInfoAt@resource://gre/modules/commonjs/toolkit/loader.js -> resource:///modules/devtools/sourceeditor/autocomplete.js:335:1
@Scratchpad/1:2:1
WCA_evalWithDebugger@resource://gre/modules/commonjs/toolkit/loader.js -> resource://gre/modules/devtools/server/actors/webconsole.js:1085:16
WCA_onEvaluateJS@resource://gre/modules/commonjs/toolkit/loader.js -> resource://gre/modules/devtools/server/actors/webconsole.js:731:20
DSC_onPacket@resource://gre/modules/commonjs/toolkit/loader.js -> resource://gre/modules/devtools/server/main.js:1225:15
LocalDebuggerTransport.prototype.send/<@resource://gre/modules/devtools/dbg-client.jsm -> resource://gre/modules/devtools/transport/transport.js:545:11
makeInfallible/<@resource://gre/modules/commonjs/toolkit/loader.js -> resource://gre/modules/devtools/DevToolsUtils.js:83:14
makeInfallible/<@resource://gre/modules/commonjs/toolkit/loader.js -> resource://gre/modules/devtools/DevToolsUtils.js:83:14

And the following log is outputted to the console:

console.log: Parse error at index 2, processing codepoint 0xNaN in state comment.

Note that the {line: 0, ch: 2} position triggers the error because the stylesheet text content is the following:

/* skins/standard/global.css */
body {font-family: sans-serif;color: ....

I don't know if the css parser state machine is able to detect comments, but in any case, I think the getInfoAt function should never fail and should at least return null when no info is found.

Comment 1

[Patrick Brosset <:pbro>]

CCing Optimizer as he worked on this feature and might be able to give some relevant information about how to fix it.

Comment 2

[Patrick Brosset <:pbro>]

Second use case, which is similar enough not to file a separate bug:
On the same stylesheet, execute the following code in scratchpad:

let editor = [...gDevTools._toolboxes][0][1].getPanel("styleeditor").UI.editors[0].sourceEditor;
editor.getInfoAt({line: 1, ch: 5});

This position corresponds to the whitespace just after the first 'body' selector.
In this case, getInfoAt returns the following object: {state: "selector", selector: " "}.

I think in the situations where the parser finds the state to be selector but the selector text is empty, then getInfoAt should return null.

Comment 3

[Patrick Brosset <:pbro>]

Third use case which fails too, but is more random, so harder to describe:

Sometimes if I run getInfoAt somewhere in a comment (which then triggers the exception) and then just after run getInfoAt on a selector right below the comment, I'll get a state:selector with a selector text that contains part of the comment.

For instance, given this stylesheet content:

/* skins/contrib/Mozilla/index.css */
#enter_bug {background: url(../../skins/cont ....

if I first getInfoAt on the comment line, and then on #enter_bug, I'll get this object:

{state: "selector", selector: "/* skins/contrib/Mozilla/index.css */\n#enter_bug"}

Comment 4

[Tom Tromey :tromey]

I think this bug was probably fixed when we moved to using the platform CSS tokenizer.
What do you think?

Comment 5

[Tom Tromey :tromey]

BTW, if this is fixed, then the workaround in StyleSheetEditor.jsm can be removed.
https://dxr.mozilla.org/mozilla-central/source/devtools/client/styleeditor/StyleSheetEditor.jsm#579

Comment 6

[Patrick Brosset <:pbro>]

You're right, this seems to be fixed now.
Let's close it. I'll file another bug to get rid of the try/catch.

Comment 7

[Patrick Brosset <:pbro>]

(In reply to Patrick Brosset [:pbrosset] [:pbro] from comment #6)
> I'll file another bug to get rid of the try/catch.
Bug 1241437