Bugzilla – Full Text Bug Listing
| Summary: | 'Home' and 'End' keys goes to the first editor | ||||||||
|---|---|---|---|---|---|---|---|---|---|
| Product: | [Eclipse Project] e4 | Reporter: | Remy Suen <remy.suen> | ||||||
| Component: | UI | Assignee: | Remy Suen <remy.suen> | ||||||
| Status: | RESOLVED FIXED | QA Contact: | Paul Webster <pwebster> | ||||||
| Severity: | normal | ||||||||
| Priority: | P3 | ||||||||
| Version: | 1.0 | ||||||||
| Target Milestone: | 1.0 M6 | ||||||||
| Hardware: | PC | ||||||||
| OS: | Windows XP | ||||||||
| Whiteboard: | |||||||||
| Attachments: |
|
||||||||
|
Description
Remy Suen
If you open two Java files then close the first one and try to use 'Home' or 'End', you'll get an exception. Technically speaking, it should be using the smart actions from JDT, see bug 310818. !MESSAGE Failure during execution of org.eclipse.ui.edit.text.goto.lineStart !STACK 0 org.eclipse.swt.SWTException: Widget is disposed at org.eclipse.swt.SWT.error(SWT.java:4083) at org.eclipse.swt.SWT.error(SWT.java:3998) at org.eclipse.swt.SWT.error(SWT.java:3969) at org.eclipse.swt.widgets.Widget.error(Widget.java:467) at org.eclipse.swt.widgets.Widget.checkWidget(Widget.java:340) at org.eclipse.swt.custom.StyledText.getSelection(StyledText.java:4638) at org.eclipse.ui.texteditor.TextNavigationAction.run(TextNavigationAction.java:60) at org.eclipse.ui.texteditor.TextNavigationAction.runWithEvent(TextNavigationAction.java:99) at org.eclipse.jface.commands.ActionHandler.execute(ActionHandler.java:121) at org.eclipse.ui.internal.handlers.E4HandlerProxy.execute(E4HandlerProxy.java:55) at sun.reflect.GeneratedMethodAccessor15.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:618) at org.eclipse.e4.core.internal.di.MethodRequestor.execute(MethodRequestor.java:42) at org.eclipse.e4.core.internal.di.InjectorImpl.invokeUsingClass(InjectorImpl.java:178) at org.eclipse.e4.core.internal.di.InjectorImpl.invoke(InjectorImpl.java:159) at org.eclipse.e4.core.contexts.ContextInjectionFactory.invoke(ContextInjectionFactory.java:103) at org.eclipse.e4.core.commands.internal.HandlerServiceImpl.executeHandler(HandlerServiceImpl.java:114) at org.eclipse.e4.ui.bindings.keys.KeyBindingDispatcher.executeCommand(KeyBindingDispatcher.java:265) at org.eclipse.e4.ui.bindings.keys.KeyBindingDispatcher.press(KeyBindingDispatcher.java:464) at org.eclipse.e4.ui.bindings.keys.KeyBindingDispatcher.processKeyEvent(KeyBindingDispatcher.java:514) at org.eclipse.e4.ui.bindings.keys.KeyBindingDispatcher.filterKeySequenceBindings(KeyBindingDispatcher.java:347) at org.eclipse.e4.ui.bindings.keys.KeyBindingDispatcher.access$0(KeyBindingDispatcher.java:293) at org.eclipse.e4.ui.bindings.keys.KeyBindingDispatcher$KeyDownFilter.handleEvent(KeyBindingDispatcher.java:75) at org.eclipse.swt.widgets.EventTable.sendEvent(EventTable.java:84) at org.eclipse.swt.widgets.Display.filterEvent(Display.java:1253) at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1051) at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1076) at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1061) at org.eclipse.swt.widgets.Widget.sendKeyEvent(Widget.java:1102) at org.eclipse.swt.widgets.Widget.sendKeyEvent(Widget.java:1098) at org.eclipse.swt.widgets.Widget.wmKeyDown(Widget.java:1807) at org.eclipse.swt.widgets.Control.WM_KEYDOWN(Control.java:4495) at org.eclipse.swt.widgets.Control.windowProc(Control.java:4190) at org.eclipse.swt.widgets.Canvas.windowProc(Canvas.java:341) at org.eclipse.swt.widgets.Display.windowProc(Display.java:4873) at org.eclipse.swt.internal.win32.OS.DispatchMessageW(Native Method) at org.eclipse.swt.internal.win32.OS.DispatchMessage(OS.java:2459) at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:3655) at org.eclipse.e4.ui.workbench.swt.internal.PartRenderingEngine$4.run(PartRenderingEngine.java:537) at org.eclipse.core.databinding.observable.Realm.runWithDefault(Realm.java:332) at org.eclipse.e4.ui.workbench.swt.internal.PartRenderingEngine.run(PartRenderingEngine.java:476) at org.eclipse.e4.workbench.ui.internal.E4Workbench.createAndRunUI(E4Workbench.java:99) at org.eclipse.ui.internal.Workbench$3.run(Workbench.java:534) at org.eclipse.core.databinding.observable.Realm.runWithDefault(Realm.java:332) at org.eclipse.ui.internal.Workbench.createAndRunWorkbench(Workbench.java:520) at org.eclipse.ui.PlatformUI.createAndRunWorkbench(PlatformUI.java:149) at org.eclipse.ui.internal.ide.application.IDEApplication.start(IDEApplication.java:115) at org.eclipse.equinox.internal.app.EclipseAppHandle.run(EclipseAppHandle.java:196) 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:369) at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:179) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:79) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:618) at org.eclipse.equinox.launcher.Main.invokeFramework(Main.java:619) at org.eclipse.equinox.launcher.Main.basicRun(Main.java:574) at org.eclipse.equinox.launcher.Main.run(Main.java:1407) at org.eclipse.equinox.launcher.Main.main(Main.java:1383) Created attachment 167993 [details] HandlerActivation patch v1 This patch fixes the problem and also bug 310818 at the same time. By disabling the other handler that's equal, we won't get into a loop. It's not entirely clear to me why bug 310818 gets fixed by this. Of course, the better question is why did this even start happening to begin with? When we switch from one editor to the next, shouldn't the first one have deactivated its handlers so that there wouldn't even need to be a priority check when the second editor has been activated? Sorry, not bug 310318, should be bug 310342. (In reply to comment #4) > Sorry, not bug 310318, should be bug 310342. And of course, I meant to say not bug 310818. :o Paul, are the handler submissions supposed to just be removed in 3.x on deactivation or are they only removed when the part has been disposed? (In reply to comment #5) > Paul, are the handler submissions supposed to just be removed in 3.x on > deactivation or are they only removed when the part has been disposed? Most handlers are activated once in the part context and then removed when the part is disposed. They honour lookup. But some of the "text actions turned into handlers" are going through the EditorActionBars/EditorActionBarContributions ... i.e. the actions are instantiated once, and then as each editor becomes active those actions have setActiveEditor(*) called on them. PW In 0505, when we change switch editors, we do not get any context notification events. In 0507+, we do and presumably find the first editor's handler, and since the comparison returns 0, no activation is performed, which seems to explain why attachment 167993 [details] would correct the problem.
Paul, I think we should at least introduce an ActivePartExpression back into actions that are registered by IKeyBindingService. When I open an editor and then switch back to the 'Package Explorer', the editor's 'Home' key handler (and possibly other things) seem to be activated at some point. 1. Active context is set to the 'Package Explorer'. 2. Context notification events are fired. HandlerActivation is notified. 3. We try to lookup a handler for "org.eclipse.ui.edit.text.goto.lineStart". 4. HandlerLookupFunction correctly returns 'null' since the active context, the 'Package Explorer' doesn't have one. 5. The expression is evaluated as being 'true' since there is no expression (!). 6. 'obj' is deemed 'null' and we activate it. Created attachment 168212 [details] HandlerActivation patch v2 When we are notified we are getting a context that is not the one we cared about. The fix is to always use our local member context so that we only ever activate/deactivate handlers in our own context which will prevent causing the overriding problem described in comment 8. Fix released to CVS HEAD. |