Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.

Bug 352077

Summary:

[Help] Trying to open Workbench Help shows an "XPCOM Error" dialog

Product:

[Eclipse Project] Platform

Reporter:

Martin Oberhuber <mober.at+eclipse>

Component:

User Assistance

Assignee:

Chris Goldthorpe <cgold>

Status:

RESOLVED FIXED

QA Contact:

Severity:

normal

Priority:

CC:

cgold, ChrisAustin, martin.gutschelhofer

Version:

3.7

Flags:

cgold: review+
ChrisAustin: review+

Target Milestone:

3.7.1

Hardware:

OS:

Linux

Whiteboard:

Attachments:

Description	Flags
Stacktrace logged when trying to show help	none
patch v1	none

Description Martin Oberhuber

2011-07-14 09:08:48 EDT

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

Comment 1 Martin Oberhuber

2011-07-14 09:11:48 EDT

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)

Comment 2 Martin Oberhuber

2011-07-14 09:50:47 EDT

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.

Comment 3 Chris Goldthorpe

2011-07-19 12:27:45 EDT

The fix looks safe, targeting 3.7.1.

Comment 4 Martin Oberhuber

2011-07-29 11:30:27 EDT

Hi Chris, is there any rough ETA when we could pick this up with an M-Build?

Comment 5 Martin Oberhuber

2011-08-08 10:40:24 EDT

Ping, could this go into 3.7.1 rc 1 ?

Comment 6 Chris Goldthorpe

2011-08-15 12:38:10 EDT

I just got back from a 2 week vacation, I'll take a look.

Comment 7 Chris Goldthorpe

2011-08-15 15:56:26 EDT

Yes, I can get this into 3.7.1

Comment 8 Chris Goldthorpe

2011-08-15 16:52:10 EDT

The patch has been committed to the 3.7 maintenance stream.

Comment 9 Chris Goldthorpe

2011-08-15 17:09:33 EDT

The patch has also been committed to HEAD, Fixed.

Comment 10 Chris Austin

2011-08-16 15:59:01 EDT

I do not have a Linux machine to test this on, but the patch looks ok.

Comment 11 Chris Goldthorpe

2011-08-24 16:44:53 EDT

The fix is in  M20110824-0800 - please verify the fix.