Bugzilla – Full Text Bug Listing
| Summary: | eclipse-installer shows an unfriendly error when the Browser widget is not available | ||||||||
|---|---|---|---|---|---|---|---|---|---|
| Product: | [Tools] Oomph | Reporter: | Martin Oberhuber <mober.at+eclipse> | ||||||
| Component: | Setup | Assignee: | Ed Merks <Ed.Merks> | ||||||
| Status: | CLOSED FIXED | QA Contact: | |||||||
| Severity: | normal | ||||||||
| Priority: | P3 | CC: | stephane.begaudeau | ||||||
| Version: | 1.1.0 | ||||||||
| Target Milestone: | --- | ||||||||
| Hardware: | PC | ||||||||
| OS: | Linux | ||||||||
| See Also: | https://git.eclipse.org/r/49236 | ||||||||
| Whiteboard: | |||||||||
| Bug Depends on: | |||||||||
| Bug Blocks: | 459836 | ||||||||
| Attachments: |
|
||||||||
Created attachment 253953 [details]
Screenshot of internal web browser
We decided to replace the browser widget with an owner-drawn List widget for RC4... New Gerrit change created: https://git.eclipse.org/r/49236 I started to play a little bit: https://git.eclipse.org/r/49236 It strikes me that the OS-specific selection/hover behavior is not what we want. Maybe a Canvas is more adequate... So I completely reimplemented the product list without a Browser and enhanced all other places where we used a browser to fall back to an alternative approach in case of failure. Martin, it's quite late in the game for such fundamental changes and it would be awfully great if you could test the new build as soon and as thouroughly as possible. Ideally on as many systems as possible: https://hudson.eclipse.org/oomph/job/integration/lastSuccessfulBuild/artifact/products The following commits contain the needed changes: b0a9407c248dd0db548e2b8fb5c20fbffada2528 fa5e2feb8cc0ac2e6376e85c8673de91b4915302 ce3ba8d538c2aefb86641d89420442e695aa662c f8baaa0754ef8af20a7d356623659c42a3132349 69dcc715694fcb0803904dad0422f2614580ce49 05b81dd7dde6baaa56431f78216435210d9b5852 db46cc4de8ffae3d49fd2945af986321c8ba31db (In reply to Eike Stepper from comment #5) Hi Eike, Where would I get the latest RC installer to test from ? The Hudson integration Build that you pointed to, or anything else ? If I navigate http://www.eclipse.org/downloads , Developer Builds, the Installer still points to http://eclipse.org/go/OOMPH_RC2_D_WIN64 (and this is the path where I used to get the installer from). Using the integration build, I still get an exception due to the Browser missing --> REOPEN: wget https://hudson.eclipse.org/oomph/job/integration/lastSuccessfulBuild/artifact/products/eclipse-installer-linux64.tar.gz tar xfz eclipse-installer-linux64.tar.gz eclipse-installer/eclipse-installer org.eclipse.swt.SWTError: No more handles [Unknown Mozilla path (MOZILLA_FIVE_HOME not set)] at org.eclipse.swt.SWT.error(SWT.java:4517) at org.eclipse.swt.browser.Mozilla.initMozilla(Mozilla.java:2231) at org.eclipse.swt.browser.Mozilla.create(Mozilla.java:687) at org.eclipse.swt.browser.Browser.<init>(Browser.java:99) at org.eclipse.oomph.setup.internal.installer.SimpleVariablePage.createContent(SimpleVariablePage.java:211) at org.eclipse.oomph.setup.internal.installer.SimpleInstallerPage.<init>(SimpleInstallerPage.java:74) at org.eclipse.oomph.setup.internal.installer.SimpleVariablePage.<init>(SimpleVariablePage.java:192) at org.eclipse.oomph.setup.internal.installer.SimpleInstallerDialog.createUI(SimpleInstallerDialog.java:185) at org.eclipse.oomph.setup.internal.installer.AbstractSimpleDialog.show(AbstractSimpleDialog.java:98) at org.eclipse.oomph.setup.internal.installer.InstallerApplication.run(InstallerApplication.java:215) at org.eclipse.oomph.setup.internal.installer.InstallerApplication.start(InstallerApplication.java:271) at org.eclipse.equinox.internal.app.EclipseAppHandle.run(EclipseAppHandle.java:196) at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.runApplication(EclipseAppLauncher.java:134) at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.start(EclipseAppLauncher.java:104) at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:380) at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:235) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source) at java.lang.reflect.Method.invoke(Unknown Source) at org.eclipse.equinox.launcher.Main.invokeFramework(Main.java:669) at org.eclipse.equinox.launcher.Main.basicRun(Main.java:608) at org.eclipse.equinox.launcher.Main.run(Main.java:1515) at org.eclipse.equinox.launcher.Main.main(Main.java:1488) BTW, I think you can test/reproduce on any Linux system with eclipse-installer -vmargs -Dorg.eclipse.swt.browser.DefaultType=mozilla -Dorg.eclipse.swt.browser.XULRunnerPath=none See https://www.eclipse.org/swt/faq.php#howusemozilla I see. It's throwing a runtime exception and the new logic Eike wrote is only catch Exception. It should probably catch Throwable to guard against all possible exceptions... IIRC, in other places where Browser is used the SWTError is explicitly caught. That way, OutOfMemoryError and similar would still "fall through" so they could be reported. On the other hand, if a viable fallback exists then catching all Throwable and trying the fallback is probably a better idea. It's a bit of a philosophical question I guess :) I'll address this ASAP, but for RC3 it's too late. I did a general sweep through all uses of the Browser widget. All are now guarded and most provide fall-back implementations in that case. http://git.eclipse.org/c/oomph/org.eclipse.oomph.git/commit/?id=6cd2ef6504431b9020f1b8caa71c69474f38ba57 I have tested again with Hudson build #1422 dated 20150609-0831: https://hudson.eclipse.org/oomph/job/integration/1422/artifact/products/eclipse-installer-linux64.tar.gz The main Oomph screen comes up fine now without Browser (thanks!) but when I select the C/C++ package it runs into this exception --> I'll REOPEN the bug: org.eclipse.swt.SWTException: Failed to execute runnable (java.lang.NullPointerException) at org.eclipse.swt.SWT.error(SWT.java:4491) at org.eclipse.swt.SWT.error(SWT.java:4406) at org.eclipse.swt.widgets.Synchronizer.runAsyncMessages(Synchronizer.java:138) at org.eclipse.swt.widgets.Display.runAsyncMessages(Display.java:3794) at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:3433) at org.eclipse.oomph.setup.internal.installer.AbstractSimpleDialog.show(AbstractSimpleDialog.java:114) at org.eclipse.oomph.setup.internal.installer.InstallerApplication.run(InstallerApplication.java:215) at org.eclipse.oomph.setup.internal.installer.InstallerApplication.start(InstallerApplication.java:271) at org.eclipse.equinox.internal.app.EclipseAppHandle.run(EclipseAppHandle.java:196) at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.runApplication(EclipseAppLauncher.java:134) at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.start(EclipseAppLauncher.java:104) at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:380) at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:235) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source) at java.lang.reflect.Method.invoke(Unknown Source) at org.eclipse.equinox.launcher.Main.invokeFramework(Main.java:669) at org.eclipse.equinox.launcher.Main.basicRun(Main.java:608) at org.eclipse.equinox.launcher.Main.run(Main.java:1515) at org.eclipse.equinox.launcher.Main.main(Main.java:1488) Caused by: java.lang.NullPointerException at org.eclipse.oomph.setup.internal.installer.SimpleVariablePage.setEnabled(SimpleVariablePage.java:783) at org.eclipse.oomph.setup.internal.installer.SimpleVariablePage$15.run(SimpleVariablePage.java:748) at org.eclipse.oomph.ui.UIUtil$4.run(UIUtil.java:494) at org.eclipse.swt.widgets.RunnableLock.run(RunnableLock.java:35) at org.eclipse.swt.widgets.Synchronizer.runAsyncMessages(Synchronizer.java:135) ... 18 more ...the installer then crashes and on the shell where I started it, I see this: (SWT:760): GLib-CRITICAL **: Source ID 320 was not found when attempting to remove it (SWT:760): GLib-CRITICAL **: Source ID 343 was not found when attempting to remove it Sorry, this was an unrelated regression caused by the Windows-only short-cut creation support. The fix is committed to master: http://git.eclipse.org/c/oomph/org.eclipse.oomph.git/commit/?id=a80e214154cd82ee006c481063a2eda22a7cd5f2 Thanks for the fixes, I used this build dated 2015-06-10 12:25am https://hudson.eclipse.org/oomph/job/integration/1425/ I can confirm that I can install now without Browser on Yocto Embedded Linux 1.7 - very cool! I found some minor glitches reported in separate bugs: Bug 466795 (likely due to matchbox-wm) Bug 466796 (cosmetic only) Bug 466797 (probably related to not having a Browser). Marking as CLOSED, thanks ! *** Bug 469807 has been marked as a duplicate of this bug. *** |
Created attachment 253952 [details] screenshot of error Build ID: Mars RC2a on Yocto Embedded Linux 64-bit When the Browser widget can not be instantiated because it's missing (xulrunner or webkitgtk), the eclipse-installer shows an unfriendly and unhelpful error message (see attached screenshot, and backtrace on the console where oomph was started). Expected behavior: Catch the SWT "No More Handles" exception and show a helpful, friendly error message similar to the one when choosing Window > Show View > Internal Web Browser on such a system.