Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
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 11:20 Go to next message
Christian Sell is currently offline Christian Sell
Messages: 51
Registered: August 2010
Member
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 #1220964 is a reply to message #1220960] Mon, 16 December 2013 11:36 Go to previous messageGo to next message
Thomas Schindl is currently offline Thomas Schindl
Messages: 5419
Registered: July 2009
Senior Member
Why not simply replacing the whole swt from 3.x through the 4.4 version?
SWT has not broken any API (its version number is still 3!)

Tom

On 16.12.13 12:20, Christian Sell wrote:
> Hello,
>
> I have just discovered from
> https://bugs.eclipse.org/bugs/show_bug.cgi?id=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 #1220978 is a reply to message #1220964] Mon, 16 December 2013 12:48 Go to previous messageGo to next message
Christian Sell is currently offline Christian Sell
Messages: 51
Registered: August 2010
Member
Thomas Schindl wrote on Mon, 16 December 2013 06:36
Why not simply replacing the whole swt from 3.x through the 4.4 version?
SWT has not broken any API (its version number is still 3!)


Never thought of that. If that is indeed an option, we will surely try it.
Re: Backport Firefox 24 integration to 3.X [message #1221005 is a reply to message #1220978] Mon, 16 December 2013 16:10 Go to previous messageGo to next message
Grant Gayed is currently offline Grant Gayed
Messages: 2151
Registered: July 2009
Senior Member
Moving up to a 4.4-stream build that has this baked in is definitely the
best approach to take if possible.

If this is not possible for some reason then you can try to just take
the latest swt mozilla code en masse, as the breadth of changes is too
large to try to take it by pieces (especially in comparison to the swt
3.7.x release). If you want to get an idea of the specific XULRunner 24
changes relative to 4.3.x then you can compare master to the
ggayed/xulrunner-24 stream (or for a historical log of the commits see
http://git.eclipse.org/c/platform/eclipse.platform.swt.git/log/?h=ggayed/xulrunner-24
going back to September 13, 2013). I think that trying to replicate
this in the 3.7.x world would be very prone to error.

Grant


On 12/16/2013 7:48 AM, Christian Sell wrote:
> Thomas Schindl wrote on Mon, 16 December 2013 06:36
>> Why not simply replacing the whole swt from 3.x through the 4.4 version?
>> SWT has not broken any API (its version number is still 3!)
>
>
> Never thought of that. If that is indeed an option, we will surely try it.
>
Re: Backport Firefox 24 integration to 3.X [message #1221277 is a reply to message #1221005] Tue, 17 December 2013 09:33 Go to previous messageGo to next message
Christian Sell is currently offline Christian Sell
Messages: 51
Registered: August 2010
Member
ok thanks guys. I think we will try by first simply replacing the SWT bundles as suggested by Thomas. I'll report here how that goes (may take a while, holidays first)

Chris
Re: Backport Firefox 24 integration to 3.X [message #1231343 is a reply to message #1221005] Tue, 14 January 2014 12:15 Go to previous messageGo to next message
Christian Sell is currently offline Christian Sell
Messages: 51
Registered: August 2010
Member
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 #1235164 is a reply to message #1231343] Thu, 23 January 2014 17:46 Go to previous messageGo to next message
Grant Gayed is currently offline Grant Gayed
Messages: 2151
Registered: July 2009
Senior Member
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 09:15 Go to previous messageGo to next message
Christian Sell is currently offline Christian Sell
Messages: 51
Registered: August 2010
Member
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 09:40]

Report message to a moderator

Re: Backport Firefox 24 integration to 3.X [message #1241013 is a reply to message #1240961] Fri, 07 February 2014 10:46 Go to previous messageGo to next message
Christian Sell is currently offline Christian Sell
Messages: 51
Registered: August 2010
Member
Hi Grant,

looking into it further, I am getting less optimistic. Not only does the generator fail on certain headers, but the generated code also relies on things like the XPCOM and nsID classes, which reside in the SWT internal packages and look handcoded, or generated by a different tool, interfacing via JNI to the native SWT DLLs. I will probably not get around the SWT Tools plug-in stuff, and more behind the corner..
Re: Backport Firefox 24 integration to 3.X [message #1251514 is a reply to message #1241013] Thu, 20 February 2014 09:52 Go to previous messageGo to next message
Christian Sell is currently offline Christian Sell
Messages: 51
Registered: August 2010
Member
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 15:20 Go to previous message
Christian Sell is currently offline Christian Sell
Messages: 51
Registered: August 2010
Member
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
Previous Topic:Gtk Error message when creating ExpandItems dynamically on linux
Next Topic:How to suppress visual selection and mouse-over in swt.widgets.Table?
Goto Forum:
  


Current Time: Thu Oct 23 15:13:12 GMT 2014

Powered by FUDForum. Page generated in 0.02152 seconds
.:: Contact :: Home ::.

Powered by: FUDforum 3.0.2.
Copyright ©2001-2010 FUDforum Bulletin Board Software