User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:188.8.131.52) Gecko/20070723 Firefox/184.108.40.206 Build Identifier: 1.9 Currently there is no way for the embedding app to execute JS code in browser's context. Eg. I need to execute a JS function, passing arguments to it. It's possible to do using IScriptContext, but it's a very internal interface. I've written a simple patch that adds a new nsIDOMScriptContainer interface to the document object. It's just a simple wrapper around nsIScriptContext. With this patch apps may access JS engine simply by XPCOM interfaces. Reproducible: Always
Created attachment 274789 [details] [diff] [review] the patch
There's no reason to expect GetScriptGlobalObject() to not return null. Certainly when dealing with data documents or documents that are being unloaded, that will happen.
Thanks for your quick reply. I'm attaching version with GetScriptGlobalObject() return value checks.
Created attachment 274797 [details] [diff] [review] an updated patch
Attachment #274797 - Flags: review?(bzbarsky)
I think sicking is a better choice of reviewer...
Attachment #274797 - Flags: review?(bzbarsky) → review?(jonas)
Comment on attachment 274797 [details] [diff] [review] an updated patch Passing the potato on to jst. He knows this better. FWIW though, the name of the interface isn't the best. Generally we use nsIDOM* interfaces for stuff that is exposed in the DOM.
Attachment #274797 - Flags: review?(jonas) → review?(jst)
Created attachment 276675 [details] [diff] [review] path Thanks, here is a changed version (it's really just a s/nsIDOMScriptContainer/nsIScriptContainer/). If you have a suggestion for a better name, I will change it.
ping. What's Jacek's next move, guys?
Probably e-mailing jst and reminding him about this review request...
Status: UNCONFIRMED → NEW
Ever confirmed: true
Status: NEW → RESOLVED
Last Resolved: 8 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.