FF8 Devmode Plugin (issue1589803)

[acl...@google.com]

Reviewers: conroy,

Description:
FF8 Devmode Plugin

Please review this at http://gwt-code-reviews.appspot.com/1589803/

Affected files:
M plugins/xpcom/ExternalWrapper.cpp
M plugins/xpcom/Makefile
A plugins/xpcom/VisualStudio/ff80-xpcom.vcproj
M plugins/xpcom/install-template.rdf
M plugins/xpcom/prebuilt/extension/chrome.manifest
A plugins/xpcom/prebuilt/ff80/include/IOOPHM.h
M plugins/xpcom/prebuilt/update.rdf

[t.br...@gmail.com]

I'll reiterate my question: is there any plan to move to js-ctypes? or
is there some better alternative? or are binary components and
recompiling every 6 weeks a necessary evil?

I mean, have you looked at the problem yet? and if so what's the
outcome? and is there a plan on your side?

If you believe js-ctypes could work, but do not have time/resources to
invest in moving to them, then maybe I could try it on my side. But if
you already looked at it and know that js-ctypes won't work, then I
won't invest time. And if you have a plan to do the move on your side,
then I'll wait too.

http://gwt-code-reviews.appspot.com/1589803/diff/1/plugins/xpcom/Makefile
File plugins/xpcom/Makefile (right):

http://gwt-code-reviews.appspot.com/1589803/diff/1/plugins/xpcom/Makefile#newcode138
plugins/xpcom/Makefile:138: MOZALLOC_DLLFLAGS = -lmozalloc
In http://gwt-code-reviews.appspot.com/1560803/ we talked about
refactoring the MOZALLOC_DLLFLAGS, MOZJS_DLLFLAGS and ALLARCHCFLAGS
before the 'ifeq ($(BROWSER),FF40)' (just after line 94) instead of
copy/pasting them in each version.

http://gwt-code-reviews.appspot.com/1589803/

[Alan Leung]

Brian and Ray has been experimenting with different approaches to debug dev mode that steer away from browser plugins / APIs. They have had some success but from what I understand it is still in a very early stage.

My plan is to keep FF going as long as possible in the mean time.

-Alan

[John Tamplin]

On Fri, Nov 11, 2011 at 5:16 AM, <t.br...@gmail.com> wrote:

I'll reiterate my question: is there any plan to move to js-ctypes? or
is there some better alternative? or are binary components and
recompiling every 6 weeks a necessary evil?

I mean, have you looked at the problem yet? and if so what's the
outcome? and is there a plan on your side?

If you believe js-ctypes could work, but do not have time/resources to
invest in moving to them, then maybe I could try it on my side. But if
you already looked at it and know that js-ctypes won't work, then I
won't invest time. And if you have a plan to do the move on your side,
then I'll wait too.

From a brief look, it seems there is no way to get a callback when an object is no longer referenced -- this is required to free the Java object that has been wrapped on the JS side once it is no longer referenced.  It also wasn't clear how to create a JS object that wraps a Java object and intercept all the methods, but I assume that part can be done in JS.

Aside from that, it looks like it is just moving parts of the problem around.  Instead of having FF load the correct binary based on the platform, it looks like it is up to your JS code to figure out what to load (though the examples seem inconsistent, so maybe it isn't that bad).  All the calls from the plugin to the JS engine will have to be proxied through the JS code (for example, I didn't see how to allocate a JS string), which will mean a lot of boilerplate and a likely performance impact.

So, assuming the finalizer problem can be overcome, I think it would be possible but would be a lot of work to get worse performance.

--
John A. Tamplin
Software Engineer (GWT), Google

[Thomas Broyer]

On Friday, November 11, 2011 4:38:23 PM UTC+1, John A. Tamplin wrote:

On Fri, Nov 11, 2011 at 5:16 AM, <t.br...@gmail.com> wrote:

I'll reiterate my question: is there any plan to move to js-ctypes? or
is there some better alternative? or are binary components and
recompiling every 6 weeks a necessary evil?

I mean, have you looked at the problem yet? and if so what's the
outcome? and is there a plan on your side?

If you believe js-ctypes could work, but do not have time/resources to
invest in moving to them, then maybe I could try it on my side. But if
you already looked at it and know that js-ctypes won't work, then I
won't invest time. And if you have a plan to do the move on your side,
then I'll wait too.

From a brief look, it seems there is no way to get a callback when an object is no longer referenced -- this is required to free the Java object that has been wrapped on the JS side once it is no longer referenced.  It also wasn't clear how to create a JS object that wraps a Java object and intercept all the methods, but I assume that part can be done in JS.

Re. intercepting methods, it's possible using proxies (will be in EcmaScript 6; usable since Firefox 4, but discouraged): https://developer.mozilla.org/en/JavaScript/Reference/Global_Objects/Proxy

and the non-standard __noSuchMethod__: https://developer.mozilla.org/en/JavaScript/Reference/Global_Objects/Object/NoSuchMethod

 

Aside from that, it looks like it is just moving parts of the problem around.  Instead of having FF load the correct binary based on the platform, it looks like it is up to your JS code to figure out what to load (though the examples seem inconsistent, so maybe it isn't that bad).

As I understand it, in the case of the DevMode, only the "common", browser-independent, part would be "binary" (there might not even be a need for glue code, or only for calling back to the JS engine) and everything else would be done in JS; so it'd save us from compiling one version of the binary component per Gecko SDK version, only one per OS. So releasing for a new version of Firefox would mean, in the best case, only bumping the maxVersion in the update.rdf; something that can be done by anyone locally, and you no longer have to wait for the SDK to be released. That'd also make it possible (and really easy) to test/use the plugin on beta or aurora versions.

All the calls from the plugin to the JS engine will have to be proxied through the JS code (for example, I didn't see how to allocate a JS string), which will mean a lot of boilerplate and a likely performance impact.

So, assuming the finalizer problem can be overcome, I think it would be possible but would be a lot of work to get worse performance.

Searching a bit on the MDN, I don't see how the finalizer issue could be worked around, so I guess it's a show-stopper.