Community
Participate
Working Groups
Build Identifier: I20110613-1736 Eclipse 3.7 uses WebKit as the Browser's underlying renderer. That's why XULRunner crashes on a lot of Linux distributions. The solution is to add a variable (org.eclipse.swt.browser.UseWebKitGTK, for instance; this variable exists in Eclipse 3.6.2). If the variable would be set to false, Eclipse wouldn't try to use WebKit (at least when using SWT.NONE). It would also be necessary to load the org.eclipse.swt.browser.WebKitInitializer or some similar class that could set this variable before showing up the Welcome page. The user should be able to decide whether to use WebKit or not. Attached is a patch. For more details see https://issues.jboss.org/browse/JBIDE-9144 Reproducible: Always
Created attachment 198261 [details] WebKit/XULRunner patch
Request for making this a hotbug. I know this is very late in the process but this regression hard to track down and took us a lot of time to find the root cause of a sudden raise in user errors with our Visual Editor. Affiliation: Red Hat Target to get fixed: Optimal 3.7.0.GA, but I know that is not very likely but then at least provide a hotfix for it to be able to distribute as a patch update. Justification: XulRunner 1.9 is used in JBoss Tools a top 6 most downloaded plugin and JBoss Developer Studio and as far as I know MyEclipse and possibly Atpana uses/bundles it too. Until recently there had not been any problems, but since Eclipse started enabling webkit by default and now leaves no option for disabling it then it becomes impossible to run XulRunner 1.9 with Eclipse on (newer) Linux distros because of incompatibility between the sqllite libraries used by common available xulrunner libs and webkit. We wish we could just move to webkit but webkit does not provide the same custom API's needed for tight integration as XulRunner does thus it is not a viable option at this time. A viable option is if SWT would reinstate the flag that made it possible to disable loading of webkit to allow plugins that uses xulrunner to continue to work. Thank you
Please note that on Windows and OSX this problem is not present, its "only" for Linux distributions.
Created attachment 198282 [details] plug-in to try Can you try substituting the attached plug-in for the one in your Eclipse 3.7? It doesn't look for the property, but I suspect it will fix your case (need you to verify).
(In reply to comment #4) > Created attachment 198282 [details] > plug-in to try > > Can you try substituting the attached plug-in for the one in your Eclipse 3.7? > It doesn't look for the property, but I suspect it will fix your case (need you > to verify). I have tested the attached plugin using Eclipse 3.7RC4. The crash still happens. Could you describe what you have changed in the plugin or attach a patch? I have tried to load the xulrunner libraries (swt-xulrunner and swt-xpcominit) in the BrowserFactory.createWebBrowser method before (and after) calling the WebKit.isInstalled() method. That helps for Eclipse 3.7RC4, but doesn't help in Eclipse 3.7 I20110613-1736. The issue also happens on a Linux 32-bit (Ubuntu 11.04 with XULRunner 1.9.2.16, for instance). In my opinion, WebKit and XULRunner can't work simultaneously on different Linux distributions. The best solution would be to allow the user to decide what renderer to use.
The attached plug-in does what you describe, it changes BrowserFactory.createWebBrowser() to attempt to load XULRunner's libraries as the _first_ thing it does on its initial invocation. As you noted in the JBoss bug, BrowserFactory.createWebBrowser() was already doing something like this. However its initial reference to WebKit.isInstalled() was circumventing this fix since it was causing WebKitGTK's libraries to be loaded as a side-effect. > That helps for Eclipse 3.7RC4, but doesn't help in Eclipse 3.7 I20110613-1736 This is surprising because almost nothing in eclipse changed between these two builds, including swt (did not change). I can only think of two reasons you'd see a difference here: - Your I20110613-1736 is somehow set up wrong, and you're not actually running with the hack fix that you said fixed 3.7RC4 for you. Can you verify that your change that loads the XULRunner libaries up-front is definitely running? - I think p2 changed between these two builds. With your hack fix in place, can you verify that your XULRunnerInitializer is still being invoked when the first Browser instance is created by Eclipse, as must be happening for you with your 3.7RC4 case?
Created attachment 198288 [details] patch used to create comment #4 attachment patch used to create comment #4 attachment
(In reply to comment #7) > Created attachment 198288 [details] > patch used to create comment #4 attachment > > patch used to create comment #4 attachment I have tested your patch. Eclipse still crashes. XULRunnerInitializer is called. I have debugged and checked that. After that, I have added the following: BrowserFactory.java WebBrowser createWebBrowser (int style) { if (!mozillaLibsLoaded) { mozillaLibsLoaded = true; Mozilla.LoadLibraries2 (); } boolean webkitInstalled = WebKit.isInstalled (); ... Mozilla.java ... static void LoadLibraries2() { LoadLibraries(); try { Library.loadLibrary ("swt-xulrunner"); //$NON-NLS-1$ } catch (UnsatisfiedLinkError e) { SWT.error (SWT.ERROR_NO_HANDLES, e); } try { Library.loadLibrary ("swt-xpcominit"); //$NON-NLS-1$ } catch (UnsatisfiedLinkError e) { SWT.error (SWT.ERROR_NO_HANDLES, e); } } ... I was debuging VPE tests and am sure swt-xulrunner and swt-xpcominit are loaded before loading WebKit. XULRunner is initialized and the VPE editor opened, but Eclipse 3.7RC4 crashes.
(In reply to comment #6) > > > That helps for Eclipse 3.7RC4, but doesn't help in Eclipse 3.7 I20110613-1736 > > This is surprising because almost nothing in eclipse changed between these two > builds, including swt (did not change). I can only think of two reasons you'd > see a difference here Loading XULRunner libraries before WebKit libraries doesn't work either on Eclipse 3.7RC4 or on Eclipse 3.7 I20110613-1736. I probably removed the system's sqlite when testing this case using Eclipse 3.7RC4 what caused the WebKit libraries not to be loaded and XULRunner to work correctly.
If I get it right, this problem happens only for products which ship their own copy of Xulrunner, correct? At Wind River we're also shipping Xulrunner (1.9.0.10 if that matters) so we'd be affected too on Ubuntu 10.04 32-bit at least. So Eclipse 3.7 changed behavior with respect to the default Browser libs being loaded. Looks like there should be a way for a Product to specify what sort of Browser should be created for SWT.NONE requests. Such a Preference may also be interesting on Windows (eg when Xulrunner is shipped with a product and thus preferrable over IE).
(In reply to comment #10) > If I get it right, this problem happens only for products which ship their own > copy of Xulrunner, correct? > The crash can also happen when using the system's XULRunner. XULRunner uses its own sqlite because its sqlite engine isn't always compatible with the system's sqlite. If XULRunner's sqlite isn't compatible with the system's sqlite that is used by WebKit, you will get the crash.
Ok, a property will be introduced for 3.7.1 and 3.8. It will be usable on all platforms, and will allow a browser type to be specified for use by all Browser instances ("all" == at least those created with style SWT.NONE, others TBD). Patch will follow.
Created attachment 198550 [details] patch to allow specification of a browser type for SWT.NONE-style Browsers
(In reply to comment #13) > Created attachment 198550 [details] > patch to allow specification of a browser type for SWT.NONE-style Browsers The patch works fine when adding -Dorg.eclipse.swt.browser.DefaultType=mozilla manually. We, however, have to add that property programmatically. Could you add the following (or similar) code: try { Class clazz = Class.forName ("org.eclipse.swt.browser.DefaultBrowserInitializer"); //$NON-NLS-1$ } catch (ClassNotFoundException e) { /* no fragment is providing this class, which is the typical case */ } before line 129 String value = System.getProperty (PROPERTY_DEFAULTTYPE); in the Browser.java class as you made the initialization of XULRunner (see https://bugs.eclipse.org/bugs/show_bug.cgi?id=201774#c41)?
(In reply to comment #14) Sorry for the late reply. This can be added, will do it when I return next week.
Created attachment 199848 [details] patch that gives plug-ins the chance to set the "org.eclipse.swt.browser.DefaultType" property
Both parts of the change released to the 3.7.1 and 3.8 streams > 20110808.
I am getting user reports about this SQLite error too, however I am ensuring that Browser get created with SWT.MOZILLA style. Does this fix for 3.7.1 also fix the SQLite issue (XULRunner in our case being shipped together with the product and not the OS one being used) or does it only introduce a flag to use Mozilla for any Browsers created with SWT.NONE?
The only way to ensure that this error does not happen is to set the org.eclipse.swt.browser.DefaultType property. If all of your Browsers are created with style SWT.MOZILLA but a SWT.NONE-style Browser from somewhere else (eg.- the Welcome page) is encountered first then the sqlite library that's incompatible with your shipped XULRunner will be loaded, and can cause problems for your XULRunner when it's needed later.
Ok thanks.
*** Bug 357761 has been marked as a duplicate of this bug. ***
