User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:188.8.131.52) Gecko/20060614 Fedora/184.108.40.206-1.2.fc5 Firefox/220.127.116.11 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
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.
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().
Created attachment 227451 [details] [diff] [review] 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.
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.
Created attachment 227452 [details] 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
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"
(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.
> 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
discussion of the XRE_main patch continues in bug 343039
Is this still reproducible/actual?