Community
Participate
Working Groups
Build ID: M20080911-1700 Steps To Reproduce: We see this exception when running Rational UI test. The test hovers over an editor toolbar button, then closes the editor. I suspect the test runs so fast that it closes the editor before the tooltip gets hidden. More information: Detail error:org.eclipse.swt.SWTException: Widget is disposed at org.eclipse.swt.SWT.error(SWT.java:3777) at org.eclipse.swt.SWT.error(SWT.java:3695) at org.eclipse.swt.SWT.error(SWT.java:3666) at org.eclipse.swt.widgets.Widget.error(Widget.java:446) at org.eclipse.swt.widgets.Widget.checkWidget(Widget.java:384) at org.eclipse.swt.widgets.Control.getShell(Control.java:2459) at org.eclipse.jface.window.ToolTip.toolTipHide(ToolTip.java:452) at org.eclipse.jface.window.ToolTip.access$1(ToolTip.java:450) at org.eclipse.jface.window.ToolTip$6.run(ToolTip.java:537) at org.eclipse.swt.widgets.Display.timerProc(Display.java:3886) at org.eclipse.swt.internal.gtk.OS._g_main_context_iteration(Native Method) at org.eclipse.swt.internal.gtk.OS.g_main_context_iteration(OS.java:1541) at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:3031) at org.eclipse.ui.internal.Workbench.runEventLoop(Workbench.java:2382) at org.eclipse.ui.internal.Workbench.runUI(Workbench.java:2346) at org.eclipse.ui.internal.Workbench.access$4(Workbench.java:2198) at org.eclipse.ui.internal.Workbench$5.run(Workbench.java:493) at org.eclipse.core.databinding.observable.Realm.runWithDefault(Realm.java:288) at org.eclipse.ui.internal.Workbench.createAndRunWorkbench(Workbench.java:488) at org.eclipse.ui.PlatformUI.createAndRunWorkbench(PlatformUI.java:149) at com.fnfr.svt.rcp.Application.runWorkbench(Application.java:212) at com.fnfr.svt.rcp.Application.start(Application.java:197) at org.eclipse.equinox.internal.app.EclipseAppHandle.run(EclipseAppHandle.java:193) at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.runApplication(EclipseAppLauncher.java:110) at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.start(EclipseAppLauncher.java:79) at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:386) at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:179) 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:549) at org.eclipse.equinox.launcher.Main.basicRun(Main.java:504) at org.eclipse.equinox.launcher.Main.run(Main.java:1236) at org.eclipse.equinox.launcher.Main.main(Main.java:1212)
multi change because of intenion of stepping back as platform-ui committer
Also happens on Windows Build 3.4.2.M20090107-0800. And it looks like it's the same in your subversion repository as of now. I suspect the dispose listener in the constructor to be the problem. It calls ToolTip.deactivate which unregisters the ToolTipOwnerControlListener. Unfortunately, this happens before this listener could run and hide the tooltip, thus leaving it open although the owning control has been disposed. When later trying to hide the tooltip the above exception is thrown.
Here is a snippet to reproduce the bug: public static void main(String[] args) { final Display display = new Display(); final Shell shell = new Shell(display); shell.setLayout(new FillLayout(SWT.VERTICAL)); final Label label = new Label(shell, SWT.NONE); label.setText("Focus the combo\n" + "Hover over label until tool tip appears\n" + "Move the mouse wheel"); final DefaultToolTip toolTip = new DefaultToolTip(label); toolTip.setText("text"); final Combo combo = new Combo(shell, SWT.READ_ONLY); combo.setItems(new String[]{"1", "2"}); combo.addListener(SWT.Selection, new Listener() { @Override public void handleEvent(Event event) { label.dispose(); } }); shell.open(); while (!shell.isDisposed()) { if (!display.readAndDispatch()) { display.sleep(); } } display.dispose(); }
This should be quite trivial and safe to fix because all we need is to also handle the disposal
This is likely the same issue as in bug 396296.
Duplicate of bug 462065
*** This bug has been marked as a duplicate of bug 462065 ***
