Eclipse Community Forums - RDF feed
https://www.eclipse.org/forums/
Eclipse Community ForumsBackport Firefox 24 integration to 3.X
https://www.eclipse.org/forums/index.php/mv/msg/628427/1220960/#msg_1220960
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]]>Christian Sell2013-12-16T11:20:57-00:00Re: Backport Firefox 24 integration to 3.X
https://www.eclipse.org/forums/index.php/mv/msg/628427/1220964/#msg_1220964
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]]>Thomas Schindl2013-12-16T11:36:49-00:00Re: Backport Firefox 24 integration to 3.X
https://www.eclipse.org/forums/index.php/mv/msg/628427/1220978/#msg_1220978
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.
]]>Christian Sell2013-12-16T12:48:28-00:00Re: Backport Firefox 24 integration to 3.X
https://www.eclipse.org/forums/index.php/mv/msg/628427/1221005/#msg_1221005
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.
>]]>Grant Gayed2013-12-16T16:10:57-00:00Re: Backport Firefox 24 integration to 3.X
https://www.eclipse.org/forums/index.php/mv/msg/628427/1221277/#msg_1221277
Chris]]>Christian Sell2013-12-17T09:33:00-00:00Re: Backport Firefox 24 integration to 3.X
https://www.eclipse.org/forums/index.php/mv/msg/628427/1231343/#msg_1231343
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?
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]]>Grant Gayed2014-01-23T17:46:20-00:00Re: Backport Firefox 24 integration to 3.X
https://www.eclipse.org/forums/index.php/mv/msg/628427/1240961/#msg_1240961
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]]>Christian Sell2014-02-07T09:15:36-00:00Re: Backport Firefox 24 integration to 3.X
https://www.eclipse.org/forums/index.php/mv/msg/628427/1241013/#msg_1241013
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..]]>Christian Sell2014-02-07T10:46:06-00:00Re: Backport Firefox 24 integration to 3.X
https://www.eclipse.org/forums/index.php/mv/msg/628427/1251514/#msg_1251514
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]]>Christian Sell2014-02-20T09:52:46-00:00Re: Backport Firefox 24 integration to 3.X
https://www.eclipse.org/forums/index.php/mv/msg/628427/1326112/#msg_1326112
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]]>Christian Sell2014-05-01T15:20:45-00:00