On 2011-01-28 7:45 PM, Boris Zbarsky wrote:
On 1/28/11 7:33 PM, Zack Weinberg wrote:
We could put that information into the DOM exception, couldn't we?
Not without major surgery. Right now, what we have to work with is an
nsresult.
Bother.
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*:
[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, but
it does point you right at the offending call, 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).
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.)
(While I'm complaining, this isn't exactly the same problem, but the
error console messages we produce for uncaught JS exceptions that arise
from DOM APIs are full of XPCOM jargon, so they give the impression that
we're reporting some kind of internal failure rather than a bug in web
page JavaScript.)
Is this just for the ones going through XPConnect goop, or also for the
quickstubbed ones?
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?
zw
_______________________________________________
dev-tech-layout mailing list
[email protected]
https://lists.mozilla.org/listinfo/dev-tech-layout
