Community
Participate
Working Groups
I still don't know exactly why this happens, but it does seem to happen sporadically to me (and then, it appears like the only solution is restarting Eclipse to get it to work again -- I saw this in the "org.eclipse.ui.edit.text.goto.lineStart" command (but that may be because it's one of the most common actions used -- other commands such as "select to the line start" instead of just "go to the line start" were still working even when that command wasn't). I've attached a debugger to a running session where this was happening, so, I'll describe what I see below. - org.eclipse.e4.ui.bindings.keys.KeyBindingDispatcher.processKeyEvent(List<KeyStroke>, Event) is called with the parameters: ([HOME,], event). - Everything seems to be normal and it ends up calling: org.eclipse.e4.ui.bindings.keys.KeyBindingDispatcher.executeCommand(ParameterizedCommand, Event) with: ``` Command ParameterizedCommand(Command(org.eclipse.ui.edit.text.goto.lineStart,Line Start, Go to the start of the line of text, Category(org.eclipse.ui.category.textEditor,Text Editing,Text Editing Commands,true), , ,,true),null), defined: true, handled: true in context chain: WorkbenchContext -> TrimmedWindowImpl (IDEWindow) Context -> PerspectiveImpl (org.python.pydev.ui.PythonPerspective) Context -> PartImpl (org.eclipse.e4.ui.compatibility.editor) removeOnHide org.python.pydev.editor.PythonEditor (codegen_package) Context ``` - handlerService.executeHandler(parameterizedCommand, staticContext); is executed (inside the executeCommand). - It enters at org.eclipse.core.commands.Command.executeWithChecks(ExecutionEvent) and when it's called it doesn't work because `org.eclipse.core.commands.Command.handler == null` (so, it throws a `new NotHandledException("There is no handler to execute for command org.eclipse.ui.edit.text.goto.lineStart")`. So, it seems like the reason is that there's no handler for it, but what I don't know is why there's no handler for "org.eclipse.ui.edit.text.goto.lineStart" in that case (the context appears correct for me and even closing all the editors doesn't make it work -- i.e.: closing all editors and opening just a plain text editor doesn't activate that action later on (so, only an Eclipse restart makes it work again). -- so, the difference is that on the regular use case (before it fails), I can see that `org.eclipse.ui.internal.WorkbenchHandlerServiceHandler@2aabd5a0` is set as the handler (org.eclipse.core.commands.Command.handler) and when it fails that field is set to null (and it doesn't recover from that until an Eclipse restart). Still, I don't know why the handler would become null in the first place...
On another note, after debugging a bit more, it seems that it's normal for the handler to become null in: org.eclipse.ui.texteditor.KeyBindingSupportForAssistant.assistSessionStarted(ContentAssistEvent) and then it should become activated again in: org.eclipse.ui.texteditor.KeyBindingSupportForAssistant.assistSessionEnded(ContentAssistEvent) but I guess that under some racing condition sometimes this doesn't work as intended (or the assistSessionEnded isn't called as it should) or some other place (which I don't know of) does something similar and they don't talk appropriately (as a note, this is hard to reproduce reliably -- I see it happening something like once every couple days). Doing that is definitely not thread safe (but I don't know if there are threads doing anything related to changing the command handler).
By looking at the code, ReplacedCommand#activate() might be suffering from a race condition. The workaround for Bug 297834 might cause that the handler is not activated again. Would you be able to add a conditional breakpoint at this line, to validate that indeed here the problem arises?
I can add a conditional breakpoint (what would that be?). Note that it needs to be something that doesn't always happen, only something which would trigger the error or after the error is already there (because the error is hard to reproduce and happens only seldomly having to stop on regular situations is unwieldy). As a note, I stumbled once more in this yesterday and one thing I can confirm is that all of the actions overridden in the content assist are lost, not just HOME (so, things as `Ctrl+Up / Ctrl+Down` also don't work anymore), which really seems to indicate an issue with org.eclipse.ui.texteditor.KeyBindingSupportForAssistant.
(In reply to Fabio Zadrozny from comment #3) > I can add a conditional breakpoint (what would that be?). Note that it needs > to be something that doesn't always happen, only something which would > trigger the error or after the error is already there (because the error is > hard to reproduce and happens only seldomly having to stop on regular > situations is unwieldy). For such situations conditional breakpoints [1] are useful. They trigger only when a certain condition is not true, in this case, the condition when the handler restore would be skipped. So you can use as regular, until the condition becomes true. [1] https://wiki.eclipse.org/FAQ_How_do_I_set_a_conditional_breakpoint%3F
Oh, I know how conditional breakpoints work, what I can't find out is a good condition on when this happens (I can detect it after it happens, but then it's too late, I'm already in that condition)... I'm actually experimenting printing things through breakpoints to see if the tracing indicates something, but if things happen slower due to prints/debug I may not be able to reproduce it.
I would put a conditional breakpoint in KeyBindingSupportForAssistant at line 73, with contents handler.getClass().isInstance(command.getHandler()), to simulate an else statement. Or when you are changing the code, add a real else statement, and add a breakpoint in the else block. This should have least impact on timing.
As a note, I still have this issue, but so far I haven't been able to reproduce it when the debugger is connected (it seems that if I start it with a breakpoint in place changes in timing make it so that it doesn't happen anymore -- I can only manage to attach a debugger afterwards).