Community
Participate
Working Groups
Using 4.4.M6, I use Alt-Shift-F2 to turn on Menu spy, and I access the context menu (for a given resource or on a text editor), in order to get the Spy infos for the selected menu. First click: nothing happens Second click: Spy is disabled so it trigger the action related to the menu. Log shows a NPE: !ENTRY org.eclipse.ui 4 0 2014-05-07 14:20:19.712 !MESSAGE Unhandled event loop exception !STACK 0 java.lang.NullPointerException at org.eclipse.pde.internal.runtime.spy.handlers.MenuSpyHandler.handleEvent(MenuSpyHandler.java:89) at org.eclipse.swt.widgets.EventTable.sendEvent(EventTable.java:84) at org.eclipse.swt.widgets.Display.filterEvent(Display.java:1569) at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1387) at org.eclipse.swt.widgets.Display.runDeferredEvents(Display.java:3773) at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:3393) at org.eclipse.e4.ui.internal.workbench.swt.PartRenderingEngine$9.run(PartRenderingEngine.java:1122) at org.eclipse.core.databinding.observable.Realm.runWithDefault(Realm.java:332) at org.eclipse.e4.ui.internal.workbench.swt.PartRenderingEngine.run(PartRenderingEngine.java:1006) at org.eclipse.e4.ui.internal.workbench.E4Workbench.createAndRunUI(E4Workbench.java:147) at org.eclipse.ui.internal.Workbench$5.run(Workbench.java:630) at org.eclipse.core.databinding.observable.Realm.runWithDefault(Realm.java:332) at org.eclipse.ui.internal.Workbench.createAndRunWorkbench(Workbench.java:574) at org.eclipse.ui.PlatformUI.createAndRunWorkbench(PlatformUI.java:150) at org.eclipse.ui.internal.ide.application.IDEApplication.start(IDEApplication.java:125) at org.eclipse.equinox.internal.app.EclipseAppHandle.run(EclipseAppHandle.java:196) at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.runApplication(EclipseAppLauncher.java:133) at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.start(EclipseAppLauncher.java:103) at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:378) at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:232) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:606) at org.eclipse.equinox.launcher.Main.invokeFramework(Main.java:648) at org.eclipse.equinox.launcher.Main.basicRun(Main.java:603) at org.eclipse.equinox.launcher.Main.run(Main.java:1462) at org.eclipse.equinox.launcher.Main.main(Main.java:1438)
It seems like event.display.getActiveShell() returns null. Is it even normal that display.getActiveShell() can return null? Could it be an upstream (SWT) issue?
Also, this seems to be a regression compared to previous Luna milestones.
Probably related: http://stackoverflow.com/questions/16542066/get-active-shell-in-swt-even-if-the-shell-is-not-on-focus
See proposal of a patch: https://git.eclipse.org/r/26159
cc'ing Eric in case he has an idea why we can't get an active shell for the event. I'm quite happy to accept patches for the plug-in spy feature for minor improvements.
I see two possibilities that may be colluding to cause this. a) Not sure but I think that menus are themselves Shells (which is why they can go outside the bounds of the app's shell. b) Menus also spin there own version of the event loop (and grab focus)...
I didn't investigate a root cause for this issue. It used to work and it doesn't any more. I couldn't find any reason. However, the suggested patch seems a working solution, for a problem we don't fully understand ;)
Applied the fix to master: http://git.eclipse.org/c/pde/eclipse.pde.ui.git/commit/?id=1502fac06e1619d0bbf856c0b8f451b3e76c2cc0 When I follow your steps the shell is always returned correctly. However, forcing the shell to null and running your additional code finds and returns the correct shell.
(In reply to Curtis Windatt from comment #8) > When I follow your steps the shell is always returned correctly. However, > forcing the shell to null and running your additional code finds and returns > the correct shell. So it can be a platform-specific behaviour? I'm using Linux with GTK 3.8.
