The JS stack at the error is
handleEvent([object Event])@:0
XPC_SJOW_CallWrapper(handleEvent,[object Event])@:0
(XPC_SJOW_CallWrapper,handleEvent,[object
Event])@XPCSafeJSObjectWrapper.cpp:450
@:0
This is probably a Firebug problem, but why can't the error message just
say some thing useful?
jjb
I'm all for more informative error messages, and suspect that the
authors' deep context of that area resulted in what for them was a
useful message, though for you might not be, so helping everyone
understand:
- what you interpret that message to mean, and
- what you would want it to say
would be helpful.
cheers,
mike
> _______________________________________________
> dev-platform mailing list
> dev-pl...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
Now that you put it that way: I interpret the message to mean that there
is a bug in Firefox. The message is nonsense, so the program must have
some bad data which is it putting into a message.
> - what you would want it to say
I want it to give a Javascript source line number, not a C++ line number.
I want a real Javascript object name, not UnnamedClass.
I want the message in terms of operations under the control of
Javascript; "create wrapper" is not a Javascript operation so it is not
possible for sendsome.org to create a wrapper.
I want the call stack to include some code I can change to remove the
message.
But again I guess this message is just a symptom of some other problem
in Firefox. I'll have to let it slide for now.
jjb
FWIW, the string is defined here:
http://mxr.mozilla.org/mozilla-central/source/dom/locales/en-US/chrome/security/caps.properties#52
...and its only use is here:
http://mxr.mozilla.org/mozilla-central/source/caps/src/nsScriptSecurityManager.cpp#2891
~Daniel
Thanks, though I hope you were trying to be helpful to someone else.
Unfortunately I fixed a Firebug problem that caused Firebug to prevent
some messages from Ajax scripts and now I am getting lots of these messages.
jjb
The subject message typically means that script running with the
permissions of http://sendsome.org attempted to access an object that
it's not allowed to access. Specifically, the "wrapper" in this case is
the JS reflection of the underlying C++ object. Permission to create
that was denied. UnnamedClass means that the C++ object did not
indicate what kind of object it is (normal for objects not meant to be
exposed to JavaScript) and that the error reporter therefore can't tell
you what sort of object it was.
> The JS stack at the error is
> handleEvent([object Event])@:0
> XPC_SJOW_CallWrapper(handleEvent,[object Event])@:0
> (XPC_SJOW_CallWrapper,handleEvent,[object
> Event])@XPCSafeJSObjectWrapper.cpp:450
That's not much to go on; presumably the key is also what you entered
the event dispatch from (so the specific C++ code)...
> This is probably a Firebug problem, but why can't the error message just
> say some thing useful?
See above for the best it could say on the actual error it hits. If you
want it to say _why_ it hit that error, then things are even harder; I
don't have enough information here to say why something is trying to
reflect an object without classinfo into web page JS here.
-Boris
The message is not nonsense; it means exactly what it says: Script
running with a particular web site's permissions tried to touch an
object and was not allowed to. We don't know what kind of object it
was, because the reflection capabilities of C++ without RTTI are rather
limited.
> I want it to give a Javascript source line number, not a C++ line number.
You mean for the safe object wrapper code? That bit of script has no
"Javascript source line number". It's completely synthesized from
within C++ via a JSAPI method call, and exists solely to make sure that
its callee sees JS code with the right principal on the stack.
We could just not list a file/line at all, but you wouldn't be happy
with that either.
> I want a real Javascript object name, not UnnamedClass.
There is no "real Javascript object". That's the whole point. There's
a C++ object that we're not allowed to turn into a Javascript object.
We're reporting said inability.
> I want the message in terms of operations under the control of
> Javascript; "create wrapper" is not a Javascript operation so it is not
> possible for sendsome.org to create a wrapper.
Yeah, I agree the wrapper thing is overly technical. We should replace
that with "reflect into javascript" or some such.
> I want the call stack to include some code I can change to remove the
> message.
The call stack is all there is on the JS stack... The rest of it is in
C++. The thing that needs changing is presumably whatever passed an
untrusted event handler into something that only works on a trusted
object; by the time the event dispatch happens this is long since off
the stack.
> But again I guess this message is just a symptom of some other problem
> in Firefox. I'll have to let it slide for now.
<shrug>. _Someone_ is screwing up here. It might be xpconnect. It
might be Firebug. It's hard to tell given the information I have so far.
Filing a bug, with a testcase and steps to reproduce, would be a good
start at sorting out the blame, of course.
-Boris
I think Daniel was in fact trying to be helpful to you... Though I agree
that it's not immediately obvious what that security manager code is
doing without doing some reading around it.
-Boris
So that agrees with my conclusion that this message means "Something in
Firefox is broken" rather than "Your page is trying something illegal"?
>
>> The JS stack at the error is
>> handleEvent([object Event])@:0
>> XPC_SJOW_CallWrapper(handleEvent,[object Event])@:0
>> (XPC_SJOW_CallWrapper,handleEvent,[object
>> Event])@XPCSafeJSObjectWrapper.cpp:450
>
> That's not much to go on; presumably the key is also what you entered
> the event dispatch from (so the specific C++ code)...
Yes, my reaction as well.
>
>> This is probably a Firebug problem, but why can't the error message
>> just say some thing useful?
>
> See above for the best it could say on the actual error it hits. If you
> want it to say _why_ it hit that error, then things are even harder; I
> don't have enough information here to say why something is trying to
> reflect an object without classinfo into web page JS here.
? What is classinfo into the web page JS?
Maybe related? https://bugzilla.mozilla.org/show_bug.cgi?id=436953
Using Firebug 1.5a9 in FF 3.6 (6weeks ago?) The newest part of the stack
at the exception is
> jsd3250.dll!jsds_ErrorHookProc(JSDContext *, JSContext *, const char
*, JSErrorReport *, void *) Line 575 C++
jsd3250.dll!jsd_DebugErrorHook(JSContext *, const char *,
JSErrorReport *, void *) Line 354 C
js3250.dll!js_ReportErrorAgain(JSContext *, const char *,
JSErrorReport *) Line 1610 C++
js3250.dll!js_ReportUncaughtException(JSContext *) Line 1330 C++
js3250.dll!JS_ReportPendingException(JSContext *) Line 5852 C++
xpc3250.dll!nsXPCWrappedJSClass::CheckForException(XPCCallContext &,
const char *, const char *, int) Line 1123 C++
xpc3250.dll!nsXPCWrappedJSClass::CallMethod(nsXPCWrappedJS *,
unsigned short, const XPTMethodDescriptor *, nsXPTCMiniVariant *)
Line 1689 C++
xpc3250.dll!nsXPCWrappedJS::CallMethod(unsigned short, const
XPTMethodDescriptor *, nsXPTCMiniVariant *) Line 562 C++
xpcom_core.dll!PrepareAndDispatch(nsXPTCStubBase *, unsigned int,
unsigned int *, unsigned int *) Line 114 C++
xpcom_core.dll!SharedStub() Line 142 C++
gklayout.dll!nsJSURI_base::GetMutable(int *) Line 110 C++
gklayout.dll!nsJSURI_base::GetMutable(int *) Line 110 C++
Sort of, if under "in Firefox" you include all script running with the
system principal (in particular extensions). Someone's trying to hand
an object to page script that said page script should not have; the
security manager is just enforcing the "can't hand that object to that
script" rule.
>> See above for the best it could say on the actual error it hits. If
>> you want it to say _why_ it hit that error, then things are even
>> harder; I don't have enough information here to say why something is
>> trying to reflect an object without classinfo into web page JS here.
>
> ? What is classinfo into the web page JS?
You must mean "what is 'an object without classinfo'?" That being the
sort of object someone is trying to hand to web page JS.
Classinfo is an interface that allows an object to expose information
about itself (what sort of object it is, what interfaces it implements,
possibly how you go about creating another such object, etc). Any time
you see a sensible classname for a JS object that's backed by an XPCOM
C++ object in any error message, it's coming from the classinfo.
> Maybe related? https://bugzilla.mozilla.org/show_bug.cgi?id=436953
The exception in that bug is for precisely the reason above: the value
of the "location" property on those exception objects is something that
can't be exposed to web page script (as far as the security manager is
concerned) and doesn't implement nsIClassInfo.
-Boris
Ok, maybe we are getting closer. The call stack points to this code in
Firebug:
if (spy.onreadystatechange)
spy.onreadystatechange.handleEvent(event);
Here the property onreadystatechange is the request's onreadystatechange:
this.onreadystatechange = this.xhrRequest.onreadystatechange;
and the event comes from Firefox. So we have all three players here, the
system, the extension, and the page.
But the missing bit here is that most of the time the code works. So the
problem has to relate to some other condition, maybe a network error or
something.
jjb
OK, this shouldn't obviously be a problem... assuming |event| could be
exposed to web script to start with.
> Here the property onreadystatechange is the request's onreadystatechange:
> this.onreadystatechange = this.xhrRequest.onreadystatechange;
Right, which is where your safe JS object wrapper came from.
> But the missing bit here is that most of the time the code works. So the
> problem has to relate to some other condition, maybe a network error or
> something.
I'd still really like a testcase I could point my browser at to
reproduce this. At the very least I might be able to tell you what the
C++ object involved is.
-Boris
Ok I put the info in
Bug 502959
https://bugzilla.mozilla.org/show_bug.cgi?id=502959
jjb