On 1/29/11 12:12 PM, Zack Weinberg wrote:
Hang on, though -- we don't produce meaningful position information for these warnings anyway (because the CSS parser is being given the owner document of the base DOM node for the query rather than the calling JavaScript, and line number zero -- http://mxr.mozilla.org/mozilla-central/source/content/base/src/nsGenericElement.cpp#5416 ) and the error console log you get if you don't catch the exception *does*:
Yes, but for the CSS parser we often produce meaningful information about what the error is (though not where it happened, in this case).
[09:01:04.453] uncaught exception: [Exception... "An invalid or illegal string was specified" code: "12" nsresult: "0x8053000c (NS_ERROR_DOM_SYNTAX_ERR)" location: "file:///tmp/test.html Line: 14"] Of course that's full of the XPCOM jargon I was complaining about
Apart from the "nsresult" bit, the hex code for the nsresult, and the "NS_ERROR" prefix, is there other jargon?
and we could easily improve it a bit (starting with pulling out the location information and putting it into the console's file/line display).
Hmm. We have bugs on that, for what it's worth; it's not that easy last I checked.
So on that basis I support disabling CSS-parser diagnostics for all the entry points that take a short string and throw an exception on failure. (Which might only be ParseSelectorString, I don't remember anymore.)
Indeed, it's just ParseSelectorString.
Dunno. The thing I quoted above is for matchesSelector, which I think is going through xpconnect goop; can you think of a quickstubbed API that throws exceptions offhand?
matchesSelector is quickstubbed. -Boris _______________________________________________ dev-tech-layout mailing list [email protected] https://lists.mozilla.org/listinfo/dev-tech-layout
