390473 - There is no API that allows the hosting app to interact with embeded JS engine.

Status: RESOLVED WONTFIX

(Core Graveyard :: Embedding: APIs, defect)

Description

[Jacek Caban]

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1.5) Gecko/20070723 Firefox/2.0.0.5
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

Comment 1

[Jacek Caban]

Attachment: the patch

Comment 2

[Boris Zbarsky [:bzbarsky]]

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.

Comment 3

[Jacek Caban]

Thanks for your quick reply. I'm attaching version with GetScriptGlobalObject() return value checks.

Comment 4

[Jacek Caban]

Attachment: an updated patch

Comment 5

[Boris Zbarsky [:bzbarsky]]

I think sicking is a better choice of reviewer...

Comment 6

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

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.

Comment 7

[Jacek Caban]

Attachment: 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.

Comment 8

[Dan Kegel]

ping.  What's Jacek's next move, guys?

Comment 9

[Boris Zbarsky [:bzbarsky]]

Probably e-mailing jst and reminding him about this review request...