In my testing, the CSS parser is spending about 5% of its CPU time tracking the line and column of each token. This information is only used if there is an error *and* the user looks at the error console. It would be nice if we could compute it only when the error console is first opened. To do this, we would need a variation on nsIScriptError that called back into the parser to get its line and column when necessary.

The Error Console has been removed in favor of the Browser Console (see Bug 1278368), and the component is going to be removed. If this bug is also relevant in the Browser Console, please reopen and move this into Firefox -> Developer Tools: Console.

I am mass-reopening and re-componenting every single one of the Toolkit:Error Console bugs that appear to have been closed without anyone even *glancing* at whether they were relevant to the Browser Console. If you want to close a whole bunch of old bugs -- FOR ANY REASON -- it is YOUR RESPONSIBILITY to check EVERY SINGLE ONE OF THEM and make sure they are no longer valid. Do not push that work onto the bug reporters. (It's okay to close bugs that haven't been touched in years when they don't have enough information for you to figure out whether the problem is still relevant to the current software - the reporter probably isn't coming back to clarify. But that is the ONLY situation where it is okay.) (I'm going to have to do this in two steps because of the way the "change several bugs at once" form works. Apologies for the extra bugspam.)

This isn't actionable right now without specific STR or a profile, and it was opened a long time ago. Do you plan on coming back to this bug to reproduce? If not, let's resolve it.

Well, as you already know, *I* am not going to be coming back to this bug. That said, it is definitely still relevant and I'm a little at a loss; the information in the original bug description should be more than enough for someone who understands the CSS parser, and that's the person you need to tackle it. I suggest we ask dbaron whether he thinks this is worth doing, and close it if not.

OK then, moving into CSS parsing component

(Add'l: the proposal is a pure speed optimization, it's fairly small, and it would require nontrivial surgery on the error object hierarchy, which is why I never got around to it while I was active.)

Seems worth keeping bugs open on known performance optimizations that we could make even if we're not planning to make them in the immediate future.

(This might become irrelevant if stylo works out, though.)