Community
Participate
Working Groups
CQ:WIND00287897 Build ID: Eclipse 3.7 (Indigo) 32-bit Trying to open Workbench Help on a Linux system where XULRunner doesn't work shows an "XPCOM Error" dialog. After acknowledging that dialog, another dialog shows "A severe error has occurred ... do you want to exit Workbench". See also bug 315607 comment 1. This dialog is problematic because it's extremely confusing for end users who just wanted to open help - an action that should always succeed. Expected behavior: When the embedded web browser doesn't work to show Help, the system should silently fall back to using the external web browser. This does work as expected on Solaris, and it does work as expected when using the "standalone help". Steps to reproduce: The "XULRunner does not work" can be emulated on by launching with vmargs. We reproduced it on RHEL4.8, RHEL5.3 and Ubuntu. 1. eclipse -vmargs -Dorg.eclipse.swt.browser.XULRunnerPath=none 2. Help > Help Contents or 2. Window > Preferences > General > Web Browser
Created attachment 199656 [details] Stacktrace logged when trying to show help Attached stacktrace shows the failure. To me, it looks like EmbeddedBrowserFactory.isAvailable() should catch the XPCOM error and return "false" ... after all, this was just a test to see whether an embedded browser is available, and when the mere test results in an error then it's apparently not available. It would IMO be OK to log the exception (eg once per session) but downstream clients should just expect the embedded browser to not be available : org.eclipse.swt.SWTError: XPCOM error -2147467259 at org.eclipse.swt.browser.Mozilla.error(Mozilla.java:2502) at org.eclipse.swt.browser.Mozilla.initXULRunner(Mozilla.java:2464) at org.eclipse.swt.browser.Mozilla.create(Mozilla.java:672) at org.eclipse.swt.browser.Browser.<init>(Browser.java:96) at org.eclipse.help.ui.internal.browser.embedded.EmbeddedBrowserFactory.test(EmbeddedBrowserFactory.java:71) at org.eclipse.help.ui.internal.browser.embedded.EmbeddedBrowserFactory.isAvailable(EmbeddedBrowserFactory.java:51) at org.eclipse.help.internal.browser.BrowserManager.createBrowserDescriptors(BrowserManager.java:223)
Created attachment 199666 [details] patch v1 The problem here is that the seemingly innocent act of logging the XPCOM Error triggers a host of log listeners and status handlers, which end up showing the SWT Error Dialog and recommending to exit workbench. This is inappropriate here since we just probed the Browser and if it's not available for any reason, that error can not be considered fatal. Attached patch logs the issue as warning instead of an error, and wraps the SWTError in a generic exception to stop status handlers from kicking in.
The fix looks safe, targeting 3.7.1.
Hi Chris, is there any rough ETA when we could pick this up with an M-Build?
Ping, could this go into 3.7.1 rc 1 ?
I just got back from a 2 week vacation, I'll take a look.
Yes, I can get this into 3.7.1
The patch has been committed to the 3.7 maintenance stream.
The patch has also been committed to HEAD, Fixed.
I do not have a Linux machine to test this on, but the patch looks ok.
The fix is in M20110824-0800 - please verify the fix.
