On 2011-01-31 6:16 AM, Boris Zbarsky wrote:
On 1/29/11 12:12 PM, Zack Weinberg wrote:
Hang on, though -- we don't produce meaningful position information
for these warnings anyway [...]
Yes, but for the CSS parser we often produce meaningful information
about what the error is (though not where it happened, in this case).
That's true, and I would like to preserve that information, but I don't
see a good way to do it without much more drastic changes than are
practical, if we want to make the spurious messages go away. (The
*least* invasive thing I can think of is to define a whole bunch of
NS_ERROR_DOM_SYNTAX_CSS_whatever subcodes, but then we'd have no way of
grouping them together when they all needed to be treated as
DOM_SYNTAX_ERR per spec.)
In this case, selector strings are usually pretty short and I've seen
far more people complaining about useless noise in the error console
than I have complaining about not being able to figure out what was
wrong with their CSS selectors. (JS is a different story.)
[... will respond to deleted stuff here downthread ...]
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.
In that case the patch might be as simple as removing any OUTPUT_ERROR
calls from ParseSelectorString and its subroutines.
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.
Ok, then can you suggest a *non*-quickstubbed API that throws
exceptions? I'm pretty sure it does do the same thing, but I looked for
the code that handles the conversion from nsresult to JS exception (in
general) and didn't find it.
zw
_______________________________________________
dev-tech-layout mailing list
[email protected]
https://lists.mozilla.org/listinfo/dev-tech-layout
