670629 - nsNPAPIPluginInstance::GetJSContext is not exposed anymore

Status: RESOLVED WONTFIX

(Core Graveyard :: Plug-ins, defect)

Description

[lekma]

Attachment: expose nsNPAPIPluginInstance::GetJSContext

User Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.18) Gecko/20110628 Ubuntu/10.10 (maverick) Firefox/3.6.18
Build ID: 20110628231248



Actual results:

since https://bugzilla.mozilla.org/show_bug.cgi?id=637253 has landed there is no way for a plugin to get the JSContext associated with an instance. This patch try to remedy it. I'm not sure this is the right way to do it.

Comment 1

[Josh Aas]

Was your plugin using XPCOM to access the internal instance object? If so, you should definitely not be doing that. What is the higher-level goal?

Comment 2

[lekma]

I'm writing (well rewriting) a Python NPAPI plugin. I use JS_SetErrorReporter to "catch" JavaScript errors and raise exceptions in Python when Python issue a NPN_* call, I also use JS_ReportError to propagate exceptions happening in Python during NPP_* calls to JavaScript, hence the need for the JSContext. I know using the internal instance object (npp->ndata) is relying on an implementation detail but the plugin is solely targeted at XULRunner so I can live with this (as long as there is still an instance object attached to the the plugin instance :).

Maybe there is a better way to do all this.

Thanks for your help.

Comment 3

[Johnny Stenback (:jst)]

Exposing a JSContext to an NPAPI plugin is not something I think we should do, and I don't think it's something we can realistically do for out of process plugins.

I think the better way forward here is to work on a better exception handling API as part of the scriptability APIs in the NPAPI, one that would work both ways and let enough information pass through with the exceptions for this to be realistically implementable with an out of process plugin.

Comment 4

[lekma]

> I think the better way forward here is to work on a better exception
> handling API as part of the scriptability APIs in the NPAPI, one that would
> work both ways and let enough information pass through with the exceptions
> for this to be realistically implementable with an out of process plugin.
+1

From my limited experience, I think we also need a way to report errors that might happen during plugin initialization/shutdown and instance creation/setup/destruction (even though no JavaScript might be involved, I find the JavaScript Error console is still the best place to log these errors).

Comment 5

[lekma]

Should we continue on this bug or file another one for an error reporting API?

Comment 6

[Johnny Stenback (:jst)]

I think a new bug is the way to go here, please close this one as wontfix once the other bug is on file.

Comment 7

[lekma]

filed two follow up bugs (as I think there are two separate issues):
bug 673054 - Better error reporting in NPAPI
bug 673056 - Better exception handling in NPAPI