On 2011-01-31 6:36 PM, Boris Zbarsky wrote:
On 1/31/11 6:19 PM, Zack Weinberg wrote:
It seems like that code is already doing almost what it needs to,
though. For the exception we've been kicking around, it fabricates a
DOMException object with separate properties for the location, line
number, error code name, and error message.
No, XPConnect takes such an object as _input_. Then it converts it to a
string and throws that string to JS, iirc. Yes, this is absolutely
dumb... and maybe I'm misremembering. But something stupid like that
happens.
That can't be right, because if I _catch_ the exception within
JavaScript, I get a broken down DOMException.
Maybe the lossage you remember happens at the point where we convert
uncaught JS exceptions to console messages? (Which I still can't find.)
>> In that case the patch might be as simple as removing any
>> OUTPUT_ERROR calls from ParseSelectorString and its subroutines.
>
> Hmm. Yeah, that would work; there are no subroutines to remove
> from, in fact.
Is there a bug already? I can write a patch sometime this week.
> Actually, the simplest thing if you have a tree is to remove
> this line:
>
> 'nsIDOMNSElement.*'
>
> from dom_quickstubs.qsconf and rebuild, then retest matchesSelector.
Will try that when I get a chance.
zw
_______________________________________________
dev-tech-layout mailing list
[email protected]
https://lists.mozilla.org/listinfo/dev-tech-layout
