342691 - unable to initialize gtk if embedding with javaxpcom/xulrunner

Status: RESOLVED INCOMPLETE

(Core Graveyard :: Java to XPCOM Bridge, defect)

Description

[Michal Ceresna]

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.0.4) Gecko/20060614 Fedora/1.5.0.4-1.2.fc5 Firefox/1.5.0.4 pango-text
Build Identifier: 

I've tried to start XUL application from JavaXPCOM as described in
http://developer.mozilla.org/en/docs/JavaXPCOM:Embedding_Mozilla_in_a_Java_Application_using_JavaXPCOM#Working_with_XPCOM_objects
     Mozilla moz = Mozilla.getInstance();
     nsIServiceManager serviceManager = moz.getServiceManager();
     nsIAppStartup appStartup = (nsIAppStartup)serviceManager.getServiceByContractID("@mozilla.org/toolkit/app-startup;1", nsIAppStartup.NS_IAPPSTARTUP_IID);
     nsIWindowCreator windowCreator = (nsIWindowCreator)appStartup.queryInterface(nsIWindowCreator.NS_IWINDOWCREATOR_IID);
     nsIWindowWatcher windowWatcher = (nsIWindowWatcher)serviceManager.getServiceByContractID("@mozilla.org/embedcomp/window-watcher;1", nsIWindowWatcher.NS_IWINDOWWATCHER_IID);
     windowWatcher.setWindowCreator(windowCreator);
     nsIDOMWindow win = windowWatcher.openWindow(null, "chrome://your-app/content/window.xul", "mywindow", "chrome,resizable,centerscreen", null);
     windowWatcher.setActiveWindow(win);
     appStartup.run();

The code above crashes on Linux. (I guess it works fine on win32).
The problem is that gtk_init() is on Linux/GTK called in the XRE_main function
which is not available from javaxpcom, and thus never called in the code above.

Initializing the gtk indirectly, e.g. creating some SWT widget before workarounds the crash.

What would be the best way of exposing the functionality for initializing the toolkit library from java?
Should that be handled via XRE api, javaxpcom api or untreated?


Reproducible: Always

Comment 1

[Benjamin Smedberg]

The embedding application is responsible for initializing the widget toolkit (obviously XRE_InitEmbedding does not have access to argv/argc to call gtk_init(). I don't know whether the java embedding layer wants to special-case this somehow or leave it up to the individual application.

Comment 2

[jhp (no longer active)]

Interesting.  I guess I never ran into this since I ran my testcases from within Eclipse, and that would have already run gtk_init().

For a full Java app that has no platform dependencies (i.e. non-SWT), the developer would expect initEmbedding() to handle all of this.  Of course, as bsmedberg points out, initEmbedding() does not have access to argv/argc.

On the other hand, requiring the developer to call a GTK-only helper method before calling initEmbedding() seems wrong.  I think I'd be more partial to changing initEmbedding() to call gtk_init().

Comment 3

[Michal Ceresna]

Attachment: expose XRE_main

This patch makes available the method XRE_main to Java embedders.

It allows to correctly start XUL application from java. See the attached
testcase which launches ChatZilla.

The code from
http://developer.mozilla.org/en/docs/JavaXPCOM:Embedding_Mozilla_in_a_Java_Application_using_JavaXPCOM
does not worl if the XUL application provides own components or extensions.

Note, that the XRE_main method itself initializes XPCOM, so I had to add
some help methods (initJavaXPCOM, shutdownJavaXPCOM) to initialize only
the javaXPCOM layer.

Comment 4

[Benjamin Smedberg]

That's a different issue and should be in a different bug... running XRE_main from Java is "interesting", but I'm not convinced how useful it is in the real world, since XRE_main is synchronous and Java wouldn't have control of the eventloop.

Comment 5

[Michal Ceresna]

Attachment: testcase

How to test:
1)Download chatzilla XUL app from http://developer.mozilla.org/en/docs/XULRunner_Hall_of_Fame
2)unzip chatzilla-0.9.74-xr.zip
3)make sure, no other XULrunner without the xre_main patch is registred
4)update paths in Test2.java, and start

ChatZilla window should appear

Comment 6

[Benjamin Smedberg]

Please file a separate bug for this.

I don't see how this is more useful than just finding xulrunner and then running "xulrunner.exe path/to/chatzilla/application.ini"

Comment 7

[Michal Ceresna]

(In reply to comment #4)
> That's a different issue and should be in a different bug... running XRE_main
> from Java is "interesting", but I'm not convinced how useful it is in the real
> world

This is the scenario I use it for:

An XUL application which operates as slave for my Java application.

The application has a JS (IDL) component which serves as a gateway and
is I access it via Java interface thanks to javaxpcom.

I send there commands such as "load", "openTab" etc. and once loaded 
I receive back nsIDOMDocument(s) which are used for further processing.

> since XRE_main is synchronous and Java wouldn't have control of the
> eventloop.
ATM, I use thread proxy (nsIProxyObjectManager). 
Other option could be e.g. to add new GSource* into gtk event loop.

Comment 8

[Michal Ceresna]

> I receive back nsIDOMDocument(s) which are used for further processing.
processing of the nsIDOMDocument(s) is quite intensive, I'm running some machine learning (ML) algorithms on it. Therefore, I need to run mozilla in-process.

The computation works as a smart crawler doing something similiar as:

load document
(ML processing)
choose link to follow
(ML processing)
return back
(ML processing)
choose other link to follow

Comment 9

[Michal Ceresna]

discussion of the XRE_main patch continues in bug 343039

Comment 10

[Phoenix]

Is this still reproducible/actual?