306285 - Exception when I use object inherited from xpcom component as an event handler

Status: RESOLVED INACTIVE

(Core :: XPConnect, defect)

Description

[alexander :surkov (:asurkov)]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8b3) Gecko/20050719 SeaMonkey/1.0a
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8b3) Gecko/20050719 SeaMonkey/1.0a

I inherit my object from some xpcom component. When I try to use it as an event
handler then I get exception: "Error: uncaught exception: null".

Reproducible: Always

Comment 1

[alexander :surkov (:asurkov)]

Attachment: testcase

Comment 2

[Hermann Schwab]

Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.9a1) Gecko/20050828 SeaMonkey/1.1a
Using the testcase I'm getting 
Error: uncaught exception: A script from "https://bugzilla.mozilla.org" was
denied UniversalXPConnect privileges.

Maybe it depends on
Bug 296639 Split windows into an inner and outer object

Bug 304423 (window instanceof Object) returns false

Comment 3

[alexander :surkov (:asurkov)]

If you get an exception "a script from "https://bugzilla.mozilla.org" was
adenied UniversalXPConnect privileges" then you should add next prefs to your
mozilla preferences:

user_pref("capability.principal.codebase.pX.granted", "UniversalXPConnect");
user_pref("capability.principal.codebase.pX.id", "http://bugzilla.mozilla.org");

where X is next to last number of all presented such preferences.
reh

Comment 4

[Boris Zbarsky [:bzbarsky]]

This is the right behavior -- when converting a JS object to a C++ one, if there is an actual C++ object on the proto chain that will be used instead of synthesizing a new C++ object to wrap the JS object.

Comment 5

[alexander :surkov (:asurkov)]

(In reply to comment #4)
> This is the right behavior -- when converting a JS object to a C++ one, if
> there is an actual C++ object on the proto chain that will be used instead of
> synthesizing a new C++ object to wrap the JS object.
> 

If it is the right behavior then ok though it looks obscure from the view point of javascript developer. But why bug is invalid? In anycase it is not very cool to see error "uncaught exception: null".

Comment 6

[Boris Zbarsky [:bzbarsky]]

> though it looks obscure from the view point of javascript developer

That's because the javascript developer is messing with host objects in ways that are not necessarily kosher per the ECMA spec...  ;)

> But why bug is invalid?

Because the C++ object on your proto chain is not an nsIDOMEventListener, so the addEventListener call throws.  As expected.  The goal XPConnect is trying to achieve is that if you extend a C++ object you can pass your extended thing to C++ and it will get the C++ object you extended.

Comment 7

[alexander :surkov (:asurkov)]

(In reply to comment #6)
> > But why bug is invalid?
> 
> Because the C++ object on your proto chain is not an nsIDOMEventListener, so
> the addEventListener call throws.  As expected.  The goal XPConnect is trying
> to achieve is that if you extend a C++ object you can pass your extended thing
> to C++ and it will get the C++ object you extended.
> 

I have in view it is needed more informative exception. I guess when I see exception null then I don't understand what I do wrong. Threafore I reopen bug. What your opinion about exception utility?

Comment 8

[Boris Zbarsky [:bzbarsky]]

> What your opinion about exception utility?

By the time the exception is being thrown, all we know is that the interface we want is not implemented on the object you passed in.  I doubt that it's worth redesigning XPConnect around this use case, but I'm not a module owner, so I'm not really at liberty to wontfix this.

Comment 9

[Mike Shaver (:shaver emeritus)]

(In reply to comment #4)
> This is the right behavior -- when converting a JS object to a C++ one, if
> there is an actual C++ object on the proto chain that will be used instead of
> synthesizing a new C++ object to wrap the JS object.

I'm not sure that I agree that it's the right behaviour, since it makes it impossible to override default behaviours in JS in the "natural".  With any other JS object that was passed in here, we would assume that it could implement the interface in question, and give a slightly better error message when we tried to call it.  (We could give a much better error message if we did something like the __LOCATION__ property that I put on JS components, and used that information when trying to call a method that's not there.)

(I do agree that it's the explicitly-designed behaviour.)

And if we are unwrapping to something in the proto chain, we know at the time that addEventListener is called that the C++ object doesn't support the required interface, so we should be able to say so and give a decent source co-ordinate.

I think we should find a way to report a better error here, even if we preserve this IMO-questionable proto-walking-and-unwrapping, so let's leave it open and assigned to nobody@.  Is there a status whiteboard thing for error reporting deficiencies?

Comment 10

[BMO Automation]

Per policy at https://wiki.mozilla.org/Bug_Triage/Projects/Bug_Handling/Bug_Husbandry#Inactive_Bugs. If this bug is not an enhancement request or a bug not present in a supported release of Firefox, then it may be reopened.