Bugzilla – Full Text Bug Listing
| Summary: | [Browser] With the SystemBrowserInstance, IWebBrowser#openURL() fails unless called on the Display Thread | ||
|---|---|---|---|
| Product: | [Eclipse Project] Platform | Reporter: | Martin Oberhuber <mober.at+eclipse> |
| Component: | UI | Assignee: | Eric Moffatt <emoffatt> |
| Status: | VERIFIED FIXED | QA Contact: | |
| Severity: | normal | ||
| Priority: | P3 | CC: | cgold, grant_gayed, prakash, pwebster |
| Version: | 3.6.2 | ||
| Target Milestone: | 4.2.1 | ||
| Hardware: | PC | ||
| OS: | Linux-GTK | ||
| Whiteboard: | |||
Steps to Reproduce:
1. On Linux-GTK, launch Eclipse
2. Window > Preferences > Help > Web Browser.
- Verify that the System Web Browser is found.
3. Have some app/snippet run this snippet, which opens an URL from a
background Job:
IProgressService ps = PlatformUI.getWorkbench().getProgressService();
ps.busyCursorWhile(new IRunnableWithProgress() {
public void run(IProgressMonitor monitor)
throws InvocationTargetException, InterruptedException {
try {
WebBrowserUtil.getExternalBrowser().openURL(url);
} catch (PartInitException e) {
throw new InvocationTargetException(e);
}
}
});
For testing, this snippet can be put into HelpContentsAction#run(), then
Help > Help Contents exhibits the same problem.
I'm not sure what's the best way solving this problem, since the Display Thread may be blocked and this not available for syncExec(). The method is meant to be synchronous so asyncExec() may also not be a good idea. Perhaps the best approach is this:
- SystemBrowserInstance probes if running on Display Thread
- If yes, then result of Program#findProgram("html") is cached
- If no, then the cached result is used (cause it's known to fail otherwise)
This approach might work fine since in most cases it's called from the Display Thread. As an additional measure, IWebBrowser#openURL() could add documentation that it's recommended to be run on the Display Thread.
Browser component is maintained by UA Ping, I think as a first simple step to address this, IWebBrowser#openURL() should add documentation that it's recommended to be run on the Display Thread. This would help clients do the right thing in the future. In fact, I think documenting this limitation which already exists is quite logical, since opening an URL in a Web Browser is a UI interaction. I think Martin's suggestion is a good one. Sending back to platform UI to add JavaDoc comments to org.eclipse.ui.browser.IWebBrowser, which is in the bundle org.eclipse.ui.workbench. Do either of you know if any similar restrictions apply to any of the other IWebBrowser methods ? I'll take this one...I've marked it for M6 just to make sure it doesn't disappear off of my radar... getId() does not need to be run on the UI thread. For consistency if we document the restriction that openURL() can only be called from the UI thread we should do the same for close(). commit 38c313384663a3e47ff3f54831cd92d4dad0540e Updated the javadoc as per Chris' comments... Verified (visually) in M20120829-1200. |
CQ:WIND00277253 When the Web Browser is configured to use the System Browser, calling IWebBrowser#openURL() on a Thread other than the Display thread fails with following message: "Could not open a Web Browser because there are none configured. Check the Web Browser Preferences." This is highly confusing for end users, because one (or even more) web browsers are properly configured. It's also confusing for end users, becasue IWebBrowser#openURL() API does not mention that it must be called on the Display Thread. The reason for the problem is, that SWT Program#findProgram() is used in SystemBrowserInstance, and that API only works on the Display Thread.