User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; de; rv:220.127.116.11) Gecko/20090715 Firefox/3.5.1 (.NET CLR 3.5.30729) Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 6.1; de; rv:18.104.22.168) Gecko/20090715 Firefox/3.5.1 (.NET CLR 3.5.30729) In https://developer.mozilla.org/en/XPCNativeWrapper it says: "An XPCNativeWrapper limits access to the properties and methods of the object it wraps. The only properties and methods accessible through an XPCNativeWrapper are those that are defined in IDL or defined by DOM Level 0." This is not true for XBL widgets that implement IDL interfaces. The only way to access the properties and methods defined in the widget, is to use wrappedJSObject. You should be able to use QueryInterface on the wrapper to gain access to properties and methods defined in the given interface - which the XBL widget obviously has to implement. This way you have a common method of accessing the properties of a widget, independent of whether the element is wrapped or not. Thanks in advance! Reproducible: Always
Could the new XPCNativeWrapper.unwrap() help with this?
well. don't really see a big difference between wrappedJSObject and unwrap (though there is not much information available about unwrap). The problem is that you can't access a xbl-element the same way from chrome as you would access it from content, because of the wrapper. In my particular case, I wanted to write code that can work with xbl-elements, where I am not sure whether they are in chrome or content (both possible) and I don't want to check all the time if it is a XPCNativeWrapper or not. Thus it would be nice if you could do a QueryInterface on the wrapper (just like you can on a normal xbl-element) to be able to access the attributes and methods. Then the code for a non-wrapped xbl-element and wrapped xbl-element would be the same, though you have the overhead of defining an IDL interface. Does that make sense? Cheers.
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.
Status: UNCONFIRMED → RESOLVED
Last Resolved: 9 months ago
Resolution: --- → INACTIVE
You need to log in before you can comment on or make changes to this bug.