I just found this thread, and Boris' response has been helpful too me, because I have the same problem. Thanks Boris. It's a work in progress, but so far I seem to be able to to get past the security checks for JS okay. I do this by using classinfo and pretending to be a DOM node with the flag nsIClassInfo::DOM_OBJECT. I followed the XMLHttpRequest to figure out how to expose a constructor to JS. I was able to do this, but it wasn't easy, because a lot of the XMLHttpRequest code uses MOZILLA_INTERNAL_API. My components requires MOZILLA_STRICT_API, because they are both used in a stand-alone application, and they will be used with a firefox NP plugin. I can't statically link to things like nsDOMClassInfo or js3250, because they are different for each release of FF.
However, I've found that it is possible with some trickery to use XMLHttpRequest as an example to get past the security issue for our own components. My current problem is that the XPConnect wrapper gets garbage collected for my custom components, when the custom components are still alive. At this point, any JS functions that I've added to the wrapper are destroyed, and a new wrapper is created next time the object is referenced. According to the description of bug 283129, DOM nodes have their wrappers preserved, so that properties added from JS are kept. I'd like to do the same thing for our components, and I've found out that calling nsIXPCScriptNotify::PreserveWrapper seems to do what I want. Unfortunately, the current release of FF requires the wrapper to be QI to nsIDOMNode. Furthermore, this code has changed on head, and the wrapper must be QI to nsIDOMGCParticipant, instead. I'm not sure my components should be implementing either of these interfaces, and I'm concerned that it would be difficult to correctly implementat both or either of them. Has the code on head stabilized? I don't want to go to the trouble of getting some great hack to work, if it is going to be broken by changes in the near future, anyway. I know FF 2.0 is coming out soon, but I'm not sure whether the new approach (with nsIDOMGCParticipant) will come into effect? Is there an easy way to tell? Are users of MOZILLA_STRICT_API supposed to be able to preserve their wrappers and corresponding JS properties? If this is the case, then what advice can be given on how to do this? It is tempting to use MOZILLA_INTERNAL_API and create a dependency on js3250.dll and other internal Mozilla dlls. We have successfully done this for embedding XPCOM and Mozilla components into our stand-alone application and our ActiveX control. It would be ironic, if our choice of XPCOM technology precludes us from creating an NP plugin for Firefox, because we are forced to use MOZILLA_INTERNAL_API. Any direction on this issue is much apreciated. "Boris Zbarsky" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] > huazilin wrote: >> Are there three methods in What your above suggestion or one method >> ,but need three steps for eventually solve the problem? > > There are two problems that need to be solved: > > 1) How to get the security manager to allow creation of a JS wrapper for > you > C++ object. > 2) How to expose a constructor for that object to JS. > > To solve #1, you need to either have classinfo or implement > nsISecurityCheckedComponent appropriately. > > To solve #2, you want to attach a constructor to the global object. > >> If you have time and have some >> implementing examples send to me ,I will appreciate you very very much. > > The XMLHttpRequest implementation in Gecko 1.8.0.x _is_ an implementation > example. > >> May be you could give me a simple example > > There isn't one that I know of... > > -Boris _______________________________________________ dev-tech-xpcom mailing list [email protected] https://lists.mozilla.org/listinfo/dev-tech-xpcom
