Home » Eclipse Projects » Standard Widget Toolkit (SWT) » Backport Firefox 24 integration to 3.X
| Backport Firefox 24 integration to 3.X [message #1220960] |
Mon, 16 December 2013 06:20  |
Eclipse User |
|
|
|
Hello,
I have just discovered from Bug 422561 that Firefox 24 is now supported for Eclipse 4.4. We are embedding FF (XULRunner 10) in an Eclipse 3.7 based application and have a need for upgrading FF to a more recent version. However, porting the app to 4.4 seems unrealistic, as according to our preliminary tests that would generate lots of issues with no benefits.
My question is therefore: does anyone (Grant?) see a chance of backporting the integration to 3.x? We do have some C/C++ knowhow at hand, so that should not be the problem.
thanks,
Christian Sell
|
|
| | | | | |
| Re: Backport Firefox 24 integration to 3.X [message #1235164 is a reply to message #1231343] |
Thu, 23 January 2014 12:46  |
| Eclipse User |
|
|
|
Hi, sorry for the late response,
SWT has a tool that parses XPCOM header files and generates the
corresponding nsI*.java files and XPCOM.VtblCall(...) native function
definitions (works for most header files). You can get the tool at
http://git.eclipse.org/c/platform/eclipse.platform.swt.git/tree/bundles/org.eclipse.swt.tools/Mozilla%20Generation/org/eclipse/swt/tools/internal/MozillaGenerator.java
.. To use it just set the GECKO, TARGET_FOLDER and XPCOM_HEADERS values
in its source appropriately.
For each generated nsI*.java class I would suggest deleting its function
calls that you do not use so that you can see if all of the required
XPCOM.VtblCall(...) function definitions are already there. Hopefully
they will be, because otherwise you will need to set up to re-compile
swt's xulrunner library on each of your supported platforms (this is a
different topic altogether). If you do need to add new
XPCOM.VtblCall(...) function definitions then you should have the SWT
Tools plug-in installed in your workspace, as it will detect them and
generate the corresponding JNI code in xpcom.cpp. To get the SWT Tools
plug-in go to Help > Install New Software..., Work with:
http://eclipse.org/swt/updates/4.4 .
If you have follow-up questions then CC me when responding to the
newsgroup, as I have not been here as much lately.
HTH,
Grant
On 1/14/2014 7:15 AM, Christian Sell wrote:
> Hello Grant,
>
> I have begun planning on the experiment of replacing the SWT version in
> our Eclipse 3.7-based application with the latest SWT which supports
> XULRunner >= 24. However, I am running into an issue that has been much
> discussed elsewhere: what to do with JavaXPCOM-dependent code. It turns
> out that our dependency is so deep that I'd rather reimplement the nsI*
> interfaces via JNI backed by native code than try to hack something
> together based on Javascript (that was my initial plan, not sure how
> realistic). Given that the SWT Mozilla integration seems to be doing
> just that internally, do you have any recommendations how to approach this?
>
> Thanks,
> Christian
|
|
|
| Re: Backport Firefox 24 integration to 3.X [message #1240961 is a reply to message #1235164] |
Fri, 07 February 2014 04:15 |
| Eclipse User |
|
|
|
Hello Grant,
thanks for the info, seems useful, indeed (hopefully it works, too). However, when running the generator over nsIDocShell.h and nsIDOMWindow.h, it fails with an ArrayIndexOutOfBoundsException. How about just copying those classes from the internal SWT packages?
And one more question:
when the tool is done generating the classes, it writes a number of lines to stdout, some of which contain "!ERROR UNKNOWN C TYPE" messages (see example below). Doesnt sound encouraging:
static final native int VtblCall(int fnNumber, int /*long*/ ppVtbl, !ERROR UNKNOWN C TYPE <bool >! arg0);
what does that error mean? What am I supposed to do with the list?
regards,
Christian
[Updated on: Fri, 07 February 2014 04:40] by Moderator |
|
| |
| Re: Backport Firefox 24 integration to 3.X [message #1251514 is a reply to message #1241013] |
Thu, 20 February 2014 04:52 |
| Eclipse User |
|
|
|
for the record: we have done as Thomas suggested, replacing the SWT bundles in our 3.7-based development target with the latest SWT bundles taken from 4.4M5. All seems to go well. We are bundling XULRunner 24. With regard to the missing JavaXPCOM classes, we have moved all uses of those classes behind a facade interface and then reimplemented that interface as a JNI/C DLL which interacts with native XPCOM. To do that, we needed access to the native address of the nsIWebBrowser object underlying the SWT Mozilla browser. Fortunately, there is a trick to obtain that address (which otherwise is hidden deep inside the internal SWT class structure): when you call Browser#getWebBrowser() on a Browser with SWT.MOZILLA style, SWT will try to find a class named org.mozilla.xpcom.Mozilla on the classpath. If one is found, an instance is created and the "wrapXPCOMObject(long address, String nsIID)" method is looked up and called. That method, as it turns out, is passed an address that can be safely cast to an (nsIWebBrowser *) on the C side! From there, everything else is a piece of cake!
My attempts to make use of the MozillaGenerator thingy failed - there were too many loose ends.
Heres a few more lessons learned so far:
- components are not registered automatically in XULRunner 24. You need to add code to interact with the nsIComponentRegistrar
- C or C++ code is well suited as a glue between Java and XPCOM. However, if you have more complex stuff to do (we have code that manipulates the DOM), Javascript is the way to go (according to Benjamin Smedberg, the master of XULRunner). In those cases, you will want to create a Javascript XPCOM component and call that via JNI/C
what remains for us is registration of plugins, which is also not the same as in XULRunner 10. Still investigating
|
|
|
| Re: Backport Firefox 24 integration to 3.X [message #1326112 is a reply to message #1251514] |
Thu, 01 May 2014 11:20 |
| Eclipse User |
|
|
|
I have to add to the previous message:
Meanwhile we have found one compatibility issue between the SWT from 4.4 and the ui.platform code in 3.7, which resulted in the minimize/maximize buttons for views not working. We were forced to fix it by changing the ui.platform source code in one place
|
|
|
Goto Forum:
Current Time: Tue Jul 22 18:13:03 EDT 2025
Powered by FUDForum. Page generated in 0.05664 seconds |
Home