Community
Participate
Working Groups
4.3 and latest N-build. 1. paste the following snippet into the 'Package Explorer': public class C { Ha } 2. place caret after "Ha" and start content assist 3. with the left mouse button click into the Javadoc 4. with the left mouse button click into the editor ==> part is not active but caret is there and one can type. Most key bindings don't work anymore.
Might also be a focus issue related to the Browser widget. On the other hand, the same scenario works in 3.x.
*** Bug 421343 has been marked as a duplicate of this bug. ***
I can also reproduce this on GTK. Even without having the Browser widget available (launch Eclipse with -Dorg.eclipse.swt.browser.DefaultType=mozilla but don't have XULRunner properly configured). Key bindings start to work again after a context switch (e.g. give focus to a view or another application and then back to editor). org.eclipse.e4.ui.bindings.keys.KeyBindingDispatcher#executeCommand(..) gets called even in the bad state, but HandlerServiceImpl.lookUpHandler(..) doesn't find a handler any more. When I log invocations of EclipseContext#activate() and deactivate(), I see that deactivate() is called when the user directly clicks into the Javadoc without giving focus to the proposals list first (step 3). In step 4, a few more calls to these methods occur, but the last one is deactivate(), which leaves us in the broken state. Could be because there are two nested "In Dialog" shells involved. Here's the stacktrace to the final invocation of deactivate(): org.eclipse.e4.core.internal.contexts.EclipseContext.deactivate(EclipseContext.java:642) at org.eclipse.e4.ui.internal.workbench.swt.ShellActivationListener$3.run(ShellActivationListener.java:150) at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:42) at org.eclipse.e4.ui.internal.workbench.swt.ShellActivationListener.deactivate(ShellActivationListener.java:145) at org.eclipse.e4.ui.internal.workbench.swt.ShellActivationListener.access$0(ShellActivationListener.java:131) at org.eclipse.e4.ui.internal.workbench.swt.ShellActivationListener$4.widgetDisposed(ShellActivationListener.java:197) at org.eclipse.swt.widgets.TypedListener.handleEvent(TypedListener.java:123) at org.eclipse.swt.widgets.EventTable.sendEvent(EventTable.java:84) at org.eclipse.swt.widgets.Display.sendEvent(Display.java:4350) at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1057) at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1081) at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1062) at org.eclipse.swt.widgets.Widget.release(Widget.java:811) at org.eclipse.swt.widgets.Widget.dispose(Widget.java:449) at org.eclipse.swt.widgets.Decorations.dispose(Decorations.java:447) at org.eclipse.swt.widgets.Shell.dispose(Shell.java:715) at org.eclipse.jface.text.AbstractInformationControl.dispose(AbstractInformationControl.java:513) at org.eclipse.jface.text.AbstractInformationControlManager.disposeInformationControl(AbstractInformationControlManager.java:1308) at org.eclipse.jface.text.contentassist.AdditionalInfoController.disposeInformationControl(AdditionalInfoController.java:485) at org.eclipse.jface.text.AbstractInformationControlManager.handleSubjectControlDisposed(AbstractInformationControlManager.java:634) at org.eclipse.jface.text.AbstractInformationControlManager$1.widgetDisposed(AbstractInformationControlManager.java:671) at org.eclipse.swt.widgets.TypedListener.handleEvent(TypedListener.java:123) at org.eclipse.swt.widgets.EventTable.sendEvent(EventTable.java:84) at org.eclipse.swt.widgets.Display.sendEvent(Display.java:4350) at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1057) at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1081) at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1062) at org.eclipse.swt.widgets.Widget.release(Widget.java:811) at org.eclipse.swt.widgets.Widget.dispose(Widget.java:449) at org.eclipse.swt.widgets.Decorations.dispose(Decorations.java:447) at org.eclipse.swt.widgets.Shell.dispose(Shell.java:715) at org.eclipse.jface.text.contentassist.CompletionProposalPopup.hide(CompletionProposalPopup.java:1036) at org.eclipse.jface.text.contentassist.ContentAssistant.hide(ContentAssistant.java:2062) at org.eclipse.jface.text.contentassist.ContentAssistant$Closer.mouseDown(ContentAssistant.java:181) at org.eclipse.swt.widgets.TypedListener.handleEvent(TypedListener.java:192) at org.eclipse.swt.widgets.EventTable.sendEvent(EventTable.java:84) at org.eclipse.swt.widgets.Display.sendEvent(Display.java:4350) at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1057) at org.eclipse.swt.widgets.Display.runDeferredEvents(Display.java:4169) at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:3758)
*** Bug 421574 has been marked as a duplicate of this bug. ***
The stack trace is very similar to the ones I'm seeing for bug 412001, but the proposed fix for that bug has no impact here :-(
I'm this same bug on 64-bit Cocoa. I don't think there's any Browser widget involved in my scenario. In RTC, I suspect that the "My Work" view has not implemented setFocus() properly, or setFocus() doesn't succeed for some other reason. When keybindings stop working, if I turn on the Mac OS X screen reader (Command+F5), it highlights the first toolbar on the workbench window. But it doesn't seem like focus is there, since none of the arrow keys will navigate through the tool items. It seems like there's an active Shell, but no widget with focus inside that Shell. ScreenReader just picks the toolbar because it is the top-left-most control that could have focus. I'm seeing this quite often. The workaround is to type TAB, which in theory puts the focus on a focusable control. It actually fails, but at least keybindings are working again. If I hit the keybinding to bring up CSS Spy, it highlights which widget supposedly had focus. If I press TAB again, the OS gives up and focus is reset to the top-left-most toolbar.
I have steps to reproduce this reliably. 1) Move the focus onto the 'MyWorkCanvas' control, which I'm guessing is a subclass of Canvas 2) Go to another perspective 3) Come back to the first perspective For whatever reason, focus never makes it back to that widget and gets lost.
(In reply to comment #7) > I have steps to reproduce this reliably. > Thanks Randy, I'll get my Mac out, and see if I can figure it out. Can you give me a pointer to the RTC build you are using?
(In reply to Paul Elder from comment #8) > Thanks Randy, I'll get my Mac out, and see if I can figure it out. Can you > give me a pointer to the RTC build you are using? Please make sure comment 6 ff don't dilute the original bug report (comment 0), which already had trivial steps to reproduce (reliably, and just using the Eclipse SDK). (In reply to Randy Hudson from comment #6) > In RTC, I suspect that the "My Work" view has not implemented setFocus() > properly, or setFocus() doesn't succeed for some other reason. That sounds like a different bug that should be tackled in a separate bug report for RTC. If investigations in RTC reveal a bug in Eclipse, then it's time for a new bug on bugs.eclipse.org.
What does pasting a snippet into the Package Explorer mean?
> What does pasting a snippet into the Package Explorer mean? Copy the snippet text to the clipboard, activate the Package Explorer, and then invoke "Edit > Paste".
*** Bug 423888 has been marked as a duplicate of this bug. ***
This is another manifestation of bug 412001.
Verified in 4.4.0.I20140120-2000 on Win 7/64, Mac OS X 10.9.1 and Ubuntu 12.04 (x86/64)
*** Bug 432336 has been marked as a duplicate of this bug. ***
