If you think a bug might affect users in the 57 release, please set the correct tracking and status flags for Release Management.

Consider using Components method to define fast native QueryInterface for JS components

NEW
Unassigned

Status

()

Core
XPConnect
--
enhancement
8 years ago
8 years ago

People

(Reporter: WeirdAl, Unassigned)

Tracking

Trunk
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

8 years ago
99% of the time, a JavaScript component's QueryInterface method is pretty straight forward.  QueryInterface gets called a lot, though.

The idea is that XPConnect could have a hashtable of JS-based components, where the value is an array of IIDs a component defines as "I support these interfaces."  XPConnect wouldn't have to call into JS land to execute the QueryInterface call then - it would have the supported IID's right there.

Here's some sample code:

function Component() {
  Components.defineQueryInterface(this, [
    "nsIDOMEventListener"
  ]);
}
Component.prototype = {
  // ...

  // nsISupports
  QueryInterface: function(aIID) {
    // With the above defineQueryInterface call, this method never gets called.
    if (aIID.equals(Components.interfaces.nsIDOMEventListener) ||
        aIID.equals(Components.interfaces.nsISupports))
      return this;
    return null; // XPConnect will throw NO_INTERFACE
  }
}

nsXPCWrappedJSClass::CallQueryInterfaceOnJSObject or nsXPCWrappedJSClass::DelegatedQueryInterface would be a good place to ask this hashtable for any objects which registered themselves for native QI.

I'm not sure if this is needed or even a good idea.  It's just an idea that I'm throwing out here, to see if it would stick.
(Reporter)

Updated

8 years ago
OS: Windows 7 → All
Hardware: x86 → All
You need to log in before you can comment on or make changes to this bug.