7700 - All attributes appear as functions

Status: VERIFIED FIXED

(Core :: XPConnect, defect, P3)

Description

[Alec Flett]

I ran the following code on an XPConnected object:

function describe(object, name) {
  for (var i in object) {
    var value = object[i];
    if (typeof(object[i]) == "function")
      value = "[function]";

    dump(name + "." + i + " = " + value + "\n");
  }
}

When run on an nsIMsgAccountManager (see
mozilla/mailnews/base/public/nsIMsgAccountManager.idl for details) and I get
this output:
AccountManager.QueryInterface = [function]
AccountManager.createAccount = [function]
AccountManager.createAccountWithKey = [function]
AccountManager.addAccount = [function]
AccountManager.defaultAccount = [function]
AccountManager.getAccounts = [function]
AccountManager.getAccountKey = [function]
AccountManager.allIdentities = [function]
AccountManager.allServers = [function]
AccountManager.FindServersByHostname = [function]
AccountManager.GetIdentitiesForServer = [function]
AccountManager.GetServersForIdentity = [function]
AccountManager.LoadAccounts = [function]

The strange thing about this is that not all of these are functions - some of
them are attributes. For instance, "allServers" is an nsISupportsArray and
defaultAccount is an nsIMsgAccount)

After I do this, I get the crash described in #7698, when running describe() on
another XPConnected object.

Comment 1

[John Bandhauer]

JS decides that something is of type 'function' based on whether or not the
JSClass of the JSObject of the thing has a 'call' method - if it is callable
then it must be a function. XPConnect uses just one JSClass and does include a
call method that can be used by the wrapped if it implements the
nsIXPCScriptable interface. Another way to justify this is to realize that
xpidl attributes are implemented as getters and setters in the underlying native
object.

I'm marking this as invalid. If it really bugs you then reopen the bug and we
can discuss it.

Comment 2

[Alec Flett]

My only qualm was that for QA purposes, I can't run through the attributes of an
XPConnected class and just list the non-function attributes. Is there a better
way other than using typeof()?

Comment 3

[Prashant Desale]

Alec Flett, could you verify this bug.

Comment 4

[Alec Flett]

I'll verify this when I get an answer back from jband

John - my question is above - is there any way to look at an XPConnect object in
JS and know which members of the object are attributes, and which are functions?

Comment 5

[John Bandhauer]

Sorry I didn't answer your question before...

I've reconsidered. This is worth improving. I have a fix in my tree. I'll check
it in when the tree reopens (whenever that may be).

It is worth noting that not *all* attributes show as type 'function'. You
happened to only have attributes that are wrapped native xpcom objects. As I
noted before, the JS engine considers them to be functions because their JSClass
(built by xpconnect) has a 'call' method. xpconnect has been using one single
JSClass for all wrappers. It has a 'call' method because it needs one for those
(few) wrapped objects that implement the nsIXPCScriptable interface.

I have a fix that makes xpconnect use two different JSClasses: one with and one
without a 'call' method. Most wrapped native object end up with the JSClass
without the 'call' method and are thus considered to be 'objects' by the engine.

So, given the Components.classes.nsEcho object which is of type nsIJSID (in
http://lxr.mozilla.org/mozilla/source/js/src/xpconnect/idl/xpcjsid.idl), we see
the following. (NOTE that previously the 'id' attribute would show as a function
because it is a wrapped native nsIJSID).

[x:\raptor\mozilla\dist\win32_d.obj\bin]xpcshell
js> y = Components.classes.nsEcho
nsEcho
js> for(p in y) print(p + " ---- "+ typeof(y[p]))
QueryInterface ---- function
name ---- string
number ---- string
id ---- object
valid ---- boolean
equals ---- function
init ---- function
toString ---- function
createInstance ---- function
getService ---- function
js>

Anyway, until this is checked in you won't be able to distinguish between
methods and attributes that return wrapped native objects. After this goes in
you will.

Comment 6

[Alec Flett]

That rocks. Thanks alot, this is just what I need (or rather, what will make
life easier for QA to whitebox test our code)

Comment 7

[chris hofmann]

better to do this early in m8

Comment 8

[leger]

Clearing Invalid resolution.

Comment 9

[John Bandhauer]

fix checked in

Comment 10

[Prashant Desale]

Alec Flett, could you please verify this bug.

Comment 11

[Prashant Desale]

Verified.