Community
Participate
Working Groups
I saw this with a recent I-build - I20171128-2000 Pressing Cmd+O in java file didn't open the Outline View. Tried the keys multiple times but still didn't work. Closing and reopening the file in the editor fixed the problem.
I tried Ctrl+O on plugin.xml and it worked Tried a java file "A.java"-> It did not work Tried another java file -> it worked Tried again "A.java" -> it did not work Closed and reopened "A.java" -> and it worked
Anything in the error log or any specific steps or files where it doesn't work? Does it happen only on macOS or Windows/Linux as well? Please try if other shortcut keys work when Cmd+O is not working.
Nothing in error log, Did not work on mac and Windows. Did not try any other shortcut on that file.
I couldn't reproduce it with a few trails in I20171129-2000. See also bug 385278 where some key bindings stop working intermittently. bug 385278 comment #16 is similar to this issue.
This is certainly not JDT bug, tday I did Git pull and then for plugin.xml , it stopped working. All java files worked fine and opening again of plugin.xml did the trick again.
https://www.eclipse.org/eclipse/platform-text/development/bug-incomplete.htm
I can confirm on Windows. No "ctrl + " commands worked for me for the Java editor (ctrl + 1, ctrl + 2, ctrl+ o etc). Closing and reopening Java editor fixed the issue. I can't remember such case before, it must be some recent regression. Not sure if it is JDT UI only or affects all ediktors, I only saw it once in Java editor.
(In reply to Andrey Loskutov from comment #7) > I can confirm on Windows. No "ctrl + " commands worked for me for the Java > editor (ctrl + 1, ctrl + 2, ctrl+ o etc). Closing and reopening Java editor > fixed the issue. > > I can't remember such case before, it must be some recent regression. Not > sure if it is JDT UI only or affects all ediktors, I only saw it once in > Java editor. Nothing can be done without steps.
I am able to reproduce this everyday when I start my Laptop in the morning from sleep state. After that I can't reproduce it during the day.
Updated the title based on comment #5.
(In reply to Sarika Sinha from comment #9) > I am able to reproduce this everyday when I start my Laptop in the morning > from sleep state. After that I can't reproduce it during the day. You mean in just one editor or all?
(In reply to Dani Megert from comment #11) > (In reply to Sarika Sinha from comment #9) > > I am able to reproduce this everyday when I start my Laptop in the morning > > from sleep state. After that I can't reproduce it during the day. > > You mean in just one editor or all? Only in the first editor and that also works after closing and opening. Today I was not able to reproduce after moving to the new build I20171204-0850
Able to reproduce today again with Build id: I20171206-2000. Took the build and started with old workspace but did not work on it for couple of hours and then saw this behavior. No git action was involved.
May be related to bug 426557? In my case I believe I had the welcome editor closed, but I'm not sure.
*** Bug 488708 has been marked as a duplicate of this bug. ***
Andrey, could you have a look?
(In reply to Dani Megert from comment #16) > Andrey, could you have a look? I will have a look over the Christmas time. I believe this could be somewhere in the area of RetargetTextEditorAction, TextOperationAction or somewhere in the command framework, because the key shortcuts work in general (so SWT should be OK) but we do not see any effects in the *particular* editor (Text/UI land). So the working theory is that either is the right context for the command is not found, or the handler is not found, or the action can't find the editor, or the editor reports false to validateEditorInputState() so that actions do not continue. Since we can't reproduce, I could only imagine to add some more logging here and there, in cases where we don't run an action/handler/command. It is really strange to see *nothing* in a non-working editor.
Might be unrelated but shortcuts also don't work in a fresh and empty workspace. Try Crtl+3 in such a workspace-> nothing happens
(In reply to Lars Vogel from comment #18) > Might be unrelated but shortcuts also don't work in a fresh and empty > workspace. Try Crtl+3 in such a workspace-> nothing happens Please report this as an extra bug. I believe Ctrl+3 requires an active view with *selection provider*. E.g. it never works if progress or log view are active (I don't remember which one was it).
New Gerrit change created: https://git.eclipse.org/r/114773
(In reply to Eclipse Genie from comment #20) > New Gerrit change created: https://git.eclipse.org/r/114773 This is not a fix, just an attempt to add more errors to the log in case an execution event can't be handled. I still can't reproduce the problem and have no clue where it could be.
Gerrit change https://git.eclipse.org/r/114773 was merged to [master]. Commit: http://git.eclipse.org/c/platform/eclipse.platform.ui.git/commit/?id=b140def30122a542a8b23ae952eec4b88e1eaf7f
Faced this again after e git install. Saw this error log - org.eclipse.ui.PartInitException: Abnormal Workbench Condition at org.eclipse.ui.internal.WorkbenchPage.showView(WorkbenchPage.java:4385) at org.eclipse.ui.internal.WorkbenchPage.showView(WorkbenchPage.java:4350) at org.eclipse.ui.internal.quickaccess.ViewElement.execute(ViewElement.java:77) at org.eclipse.ui.internal.quickaccess.SearchField$2.handleElementSelected(SearchField.java:198) at org.eclipse.ui.internal.quickaccess.QuickAccessContents.handleSelection(QuickAccessContents.java:597) at org.eclipse.ui.internal.quickaccess.QuickAccessContents.access$0(QuickAccessContents.java:587) at org.eclipse.ui.internal.quickaccess.QuickAccessContents$4.mouseUp(QuickAccessContents.java:786) at org.eclipse.swt.widgets.TypedListener.handleEvent(TypedListener.java:221) at org.eclipse.swt.widgets.EventTable.sendEvent(EventTable.java:86) at org.eclipse.swt.widgets.Display.sendEvent(Display.java:4433) at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1086) at org.eclipse.swt.widgets.Display.runDeferredEvents(Display.java:4243) at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:3822) at org.eclipse.e4.ui.internal.workbench.swt.PartRenderingEngine$5.run(PartRenderingEngine.java:1150) at org.eclipse.core.databinding.observable.Realm.runWithDefault(Realm.java:336) at org.eclipse.e4.ui.internal.workbench.swt.PartRenderingEngine.run(PartRenderingEngine.java:1039) at org.eclipse.e4.ui.internal.workbench.E4Workbench.createAndRunUI(E4Workbench.java:153) at org.eclipse.ui.internal.Workbench.lambda$3(Workbench.java:681) at org.eclipse.core.databinding.observable.Realm.runWithDefault(Realm.java:336) at org.eclipse.ui.internal.Workbench.createAndRunWorkbench(Workbench.java:595)
*** Bug 531601 has been marked as a duplicate of this bug. ***
It was working, then I restarted Eclipse. It stopped working (though I'm assuming it wasn't already) after I clicked to close the Welcome tab. The last class I was working on is loaded on screen and I cannot delete lines with Ctrl+D. When I opened another project, Ctrl+D worked in the new project, but not the previously opened project. I close the previously loaded class I was working on using the X button on the tab, then re-open it in the recent file section (under Properties) in the File menu. Now Ctrl+D is working again. Windows 10 Pro 64-Bit (10.0, Build 15063) -- Configuration Details -- Product: Eclipse 4.7.2.20171218-0600 (org.eclipse.epp.package.java.product)Installed Features: org.eclipse.platform 4.7.2.v20171130-0510
We are facing similar issue in our custom 4.7.2 based IDE now, reported on RHEL 7.2 (GTK 3.14). As reported by two different customers, the Ctrl + keys and backspace stop to work intermittently, in Java editor. Typing works, but no shortcuts and no backspace key (why backspace??? it is not bound to any shortcut?). If it appears, it seem to be broken for all opened editors, in Eclipse only (gedit shortcuts continue to work). At some point in time the issue seem to disappear again (or via restart :-(). The problem is, that because of the randomness of the problem users can't report any meaningful steps to reproduce (it just happens), and also can't say how this issue disappear (it just happens). We have no reliable ways to reproduce it yet, but it happens in *some* environments pretty often, at least to the point where user complain about "unusable Eclipse", and in some environments we seem not to see this at all. Unfortunately we can't say where it started to misbehave, because we migrated from 3.8.2 GTK2 straight into 4.7.2 GTK3. In R&D we don't see the problem (or no one complained yet), here we had 4.6 -> 4.7 switch with no similar issues so far. The only difference is of course that in R&D we use SDK with some 3rd party plugins, customers IDE uses a lot of our own application plugins. Any hints/insights/suggestions are welcome. Right now we are still trying to get some reliable steps to reproduce the problem, with no idea in which area the bug could be. Also I wonder if someone could explain why "backspace" key is falling into the same bucket as broken "ctrl +" shortcuts (I do not see any shortcut bindings to it). I *believe* this problem could be related to changes in KeyBindingDispatcher from bug 517068 (at least it touched same place where a similar problem was fixed via bug 369860), but looking on the code I don't see how (have not debug this yet), except that the patch creates now on each key press a new (unused!) IEclipseContext without disposing this. Not sure if this causes some internal caches to overflow or to misbehave later at random point in time.
New Gerrit change created: https://git.eclipse.org/r/122227
I believe we have two different bugs here, or at least different behavior on different platforms. On Windows I've just seen the bug again, but again, this was only for a single editor and for few shortcuts only (in contrast to what we see on Linux where NO shortcuts + backspace seem to work anymore, for all editors). On Windows I see not working Ctrl+O, Ctrl+1, Ctrl+2 commands - in a single editor only, but almost all other commands in the same editor are working fine (Ctrl+N, Ctrl+3, Ctrl+Z, Ctrl+C, Ctrl+S, backspace), and only the current editor is affected. No errors in the log. This happened to me after switching the branch while the editor was showing "Versions" annotations and starting the search in the project. Observation: invoking Ctrl+Shift+L shows the list of "known commands", clicking any "broken" command in the list also doesn't perform any action. Same thing works fine in a different editor. Closing and reopening affected editor fixes the problem. Of course again I can't reproduce it immediately after it occurred (trying to repeat my last steps).
Gerrit change https://git.eclipse.org/r/122227 was merged to [master]. Commit: http://git.eclipse.org/c/platform/eclipse.platform.ui.git/commit/?id=0753d9fb8e497c928c07214b7e248631a4f6038a
Created attachment 273944 [details] Tracing options to enable if problems occur @all who will probably observe the problem in the future: starting with the 4.8 build I20180506-2000 we have a possibility to trace what the KeyBindingDispatcher does (or does not) while processing the key input. To enable the tracing for KeyBindingDispatcher, go to Preferences -> General -> Tracing -> Platform e4 Workbench UI and set "org.eclipse.e4.ui.workbench/trace" to "true". The output goes either in the file or in the console, so please make sure if the console is chosen to start Eclipse from the shell. There is *A LOT* of output, so please don't keep this tracing enabled forever. So once the problems appear, switch tracing on, *try to use* broken shortcuts in the editor and attach the generated trace output here. The output looks like: | main | 2018-05-07 10:30:08.031 | org.eclipse.e4.ui.workbench | /trace | org.eclipse.e4.ui.internal.workbench.WorkbenchLogger | trace | 159 | Command ParameterizedCommand(Command(org.eclipse.ui.edit.text.copyLineDown,Copy Lines, Duplicates the selected lines and moves the selection to the copy, Category(org.eclipse.ui.category.textEditor,Text Editing,Text Editing Commands,true), org.eclipse.ui.internal.WorkbenchHandlerServiceHandler@79f6e671, ,,true),null), defined: true, handled: true in context: WorkbenchContext | | main | 2018-05-07 10:30:08.049 | org.eclipse.e4.ui.workbench | /trace | org.eclipse.e4.ui.internal.workbench.WorkbenchLogger | trace | 159 | Event processing done for: [ALT+CTRL+ARROW_DOWN, ALT+CTRL+] in context WorkbenchContext | | main | 2018-05-07 10:30:10.023 | org.eclipse.e4.ui.workbench | /trace | org.eclipse.e4.ui.internal.workbench.WorkbenchLogger | trace | 159 | Command ParameterizedCommand(Command(org.eclipse.ui.file.save,Save, Save the current contents, Category(org.eclipse.ui.category.file,File,null,true), org.eclipse.ui.internal.WorkbenchHandlerServiceHandler@23c6556b, ,,true),null), defined: true, handled: true in context: WorkbenchContext | | main | 2018-05-07 10:30:10.036 | org.eclipse.e4.ui.workbench | /trace | org.eclipse.e4.ui.internal.workbench.WorkbenchLogger | trace | 159 | Event processing done for: [CTRL+S] in context WorkbenchContext | | main | 2018-05-07 10:30:11.888 | org.eclipse.e4.ui.workbench | /trace | org.eclipse.e4.ui.internal.workbench.WorkbenchLogger | trace | 159 | Command ParameterizedCommand(Command(org.eclipse.ui.edit.text.goto.lineEnd,Line End, Go to the end of the line of text, Category(org.eclipse.ui.category.textEditor,Text Editing,Text Editing Commands,true), org.eclipse.ui.internal.WorkbenchHandlerServiceHandler@ff18823, ,,true),null), defined: true, handled: true in context: WorkbenchContext | | main | 2018-05-07 10:30:11.894 | org.eclipse.e4.ui.workbench | /trace | org.eclipse.e4.ui.internal.workbench.WorkbenchLogger | trace | 159 | Event processing done for: [END, ] in context WorkbenchContext | | main | 2018-05-07 10:30:12.415 | org.eclipse.e4.ui.workbench | /trace | org.eclipse.e4.ui.internal.workbench.WorkbenchLogger | trace | 159 | No binding for keys: CR in context WorkbenchContext | | main | 2018-05-07 10:30:12.416 | org.eclipse.e4.ui.workbench | /trace | org.eclipse.e4.ui.internal.workbench.WorkbenchLogger | trace | 159 | Event processing forwarded for: [CR] in context WorkbenchContext | | main | 2018-05-07 10:30:12.416 | org.eclipse.e4.ui.workbench | /trace | org.eclipse.e4.ui.internal.workbench.WorkbenchLogger | trace | 159 | No binding for keys: CR in context WorkbenchContext | | main | 2018-05-07 10:30:12.416 | org.eclipse.e4.ui.workbench | /trace | org.eclipse.e4.ui.internal.workbench.WorkbenchLogger | trace | 159 | Event processing forwarded for: [CR] in context WorkbenchContext | | main | 2018-05-07 10:30:12.559 | org.eclipse.e4.ui.workbench | /trace | org.eclipse.e4.ui.internal.workbench.WorkbenchLogger | trace | 159 | No binding for keys: CR in context WorkbenchContext | | main | 2018-05-07 10:30:12.560 | org.eclipse.e4.ui.workbench | /trace | org.eclipse.e4.ui.internal.workbench.WorkbenchLogger | trace | 159 | Event processing forwarded for: [CR] in context WorkbenchContext | | main | 2018-05-07 10:30:12.560 | org.eclipse.e4.ui.workbench | /trace | org.eclipse.e4.ui.internal.workbench.WorkbenchLogger | trace | 159 | No binding for keys: CR in context WorkbenchContext | | main | 2018-05-07 10:30:12.560 | org.eclipse.e4.ui.workbench | /trace | org.eclipse.e4.ui.internal.workbench.WorkbenchLogger | trace | 159 | Event processing forwarded for: [CR] in context WorkbenchContext | | main | 2018-05-07 10:30:17.631 | org.eclipse.e4.ui.workbench | /trace | org.eclipse.e4.ui.internal.workbench.WorkbenchLogger | trace | 159 | Command ParameterizedCommand(Command(org.eclipse.ui.file.save,Save, Save the current contents, Category(org.eclipse.ui.category.file,File,null,true), org.eclipse.ui.internal.WorkbenchHandlerServiceHandler@23c6556b, ,,true),null), defined: true, handled: true in context: WorkbenchContext | | main | 2018-05-07 10:30:17.643 | org.eclipse.e4.ui.workbench | /trace | org.eclipse.e4.ui.internal.workbench.WorkbenchLogger | trace | 159 | Event processing done for: [CTRL+S] in context WorkbenchContext | | main | 2018-05-07 10:30:24.704 | org.eclipse.e4.ui.workbench | /trace | org.eclipse.e4.ui.internal.workbench.WorkbenchLogger | trace | 159 | Command ParameterizedCommand(Command(org.eclipse.ui.edit.text.delete.line,Delete Line, Delete a line of text, Category(org.eclipse.ui.category.textEditor,Text Editing,Text Editing Commands,true), org.eclipse.ui.internal.WorkbenchHandlerServiceHandler@6c249eb5, ,,true),null), defined: true, handled: true in context: WorkbenchContext | | main | 2018-05-07 10:30:24.707 | org.eclipse.e4.ui.workbench | /trace | org.eclipse.e4.ui.internal.workbench.WorkbenchLogger | trace | 159 | Event processing done for: [CTRL+D] in context WorkbenchContext | | main | 2018-05-07 10:30:26.592 | org.eclipse.e4.ui.workbench | /trace | org.eclipse.e4.ui.internal.workbench.WorkbenchLogger | trace | 159 | Command ParameterizedCommand(Command(org.eclipse.jdt.ui.edit.text.java.correction.assist.proposals,Quick Fix, Suggest possible fixes for a problem, Category(org.eclipse.ui.category.edit,Edit,null,true), org.eclipse.ui.internal.WorkbenchHandlerServiceHandler@51173c3a, ,,true),null), defined: true, handled: true in context: WorkbenchContext | | main | 2018-05-07 10:30:28.936 | org.eclipse.e4.ui.workbench | /trace | org.eclipse.e4.ui.internal.workbench.WorkbenchLogger | trace | 159 | Command ParameterizedCommand(Command(org.eclipse.ui.file.save,Save, Save the current contents, Category(org.eclipse.ui.category.file,File,null,true), org.eclipse.ui.internal.WorkbenchHandlerServiceHandler@23c6556b, ,,true),null), defined: true, handled: true in context: WorkbenchContext | | main | 2018-05-07 10:30:28.945 | org.eclipse.e4.ui.workbench | /trace | org.eclipse.e4.ui.internal.workbench.WorkbenchLogger | trace | 159 | Event processing done for: [CTRL+S] in context WorkbenchContext |
Created attachment 273959 [details] first trace log shows no handler So it looks like the problem is not the keyboard/shortcuts handling, but the context/handler. Looks like there are no handlers to execute commands. I've just got the log where Ctrl+K, Ctrl+O in Java editor refused to work - in the log we see why: | main | 2018-05-07 18:25:27.572 | org.eclipse.e4.ui.workbench | /trace | org.eclipse.e4.ui.internal.workbench.WorkbenchLogger | trace | 159 | Command ParameterizedCommand(Command(org.eclipse.jdt.ui.edit.text.java.show.outline,Quick Outline, Show the quick outline for the editor input, Category(org.eclipse.ui.category.navigate,Navigate,null,true), org.eclipse.ui.internal.WorkbenchHandlerServiceHandler@6a855c73, ,,true),null), defined: true, handled: false in context: WorkbenchContext | | main | 2018-05-07 18:25:27.573 | org.eclipse.e4.ui.workbench | /trace | org.eclipse.e4.ui.internal.workbench.WorkbenchLogger | trace | 159 | Command exception for: ParameterizedCommand(Command(org.eclipse.jdt.ui.edit.text.java.show.outline,Quick Outline, Show the quick outline for the editor input, Category(org.eclipse.ui.category.navigate,Navigate,null,true), org.eclipse.ui.internal.WorkbenchHandlerServiceHandler@6a855c73, ,,true),null) in context: WorkbenchContext | org.eclipse.core.commands.NotHandledException: There is no handler to execute for command org.eclipse.jdt.ui.edit.text.java.show.outline at org.eclipse.core.commands.Command.executeWithChecks(Command.java:507) at org.eclipse.core.commands.ParameterizedCommand.executeWithChecks(ParameterizedCommand.java:487) at org.eclipse.e4.core.commands.internal.HandlerServiceImpl.executeHandler(HandlerServiceImpl.java:204) at org.eclipse.e4.ui.bindings.keys.KeyBindingDispatcher.executeCommand(KeyBindingDispatcher.java:292) at org.eclipse.e4.ui.bindings.keys.KeyBindingDispatcher.press(KeyBindingDispatcher.java:546) at org.eclipse.e4.ui.bindings.keys.KeyBindingDispatcher.processKeyEvent(KeyBindingDispatcher.java:614) at org.eclipse.e4.ui.bindings.keys.KeyBindingDispatcher.filterKeySequenceBindings(KeyBindingDispatcher.java:405) at org.eclipse.e4.ui.bindings.keys.KeyBindingDispatcher.access$0(KeyBindingDispatcher.java:348) at org.eclipse.e4.ui.bindings.keys.KeyBindingDispatcher$KeyDownFilter.handleEvent(KeyBindingDispatcher.java:88) at org.eclipse.swt.widgets.EventTable.sendEvent(EventTable.java:86) at org.eclipse.swt.widgets.Display.filterEvent(Display.java:1190) at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1051) Now the problem seem to be the problem of contexts and/or handler management... If anyone is aware about some relevant changes in those areas around 4.7 time frame, please leave a hint.
(In reply to Andrey Loskutov from comment #31) > Now the problem seem to be the problem of contexts and/or handler > management... After starting work on proper tracing of the contexts et via bug 534612 I'm starting to think the problem of handler/context management could be coming from the problem of shell/part activation/deactivation and focus management, similar what we saw in bug 402073. Bug 402073 could be related here, at least it is an interesting read and related bugs are also very informative. Still no clue if this is some recent regression or not. On Linux with GTK3 changes this could be even platform-dependent and a result of the behavior changes of GTK3 (e.g. focus handling on dispose was a breaking change in 4.7), but we observe this on Windows too. May be we even have different bugs here resulting in a similar effect.
Created attachment 274747 [details] Trace I'm not sure whether this is releated, but since switching the target to Eclipse 4.8, I'm seeing exceptions like: org.eclipse.e4.core.di.InjectionException: org.eclipse.core.commands.NotHandledException: Handler org.eclipse.ui.internal.handlers.SelectAllHandler@72f86029 is not handled for for command Command(org.eclipse.ui.edit.selectAll,Alles auswählen, Alles auswählen, Category(org.eclipse.ui.category.edit,Bearbeiten,null,true), org.eclipse.ui.internal.WorkbenchHandlerServiceHandler@28e12bc5, ,,true) A full stacktrace can be seen in the attachment. The exception occurs only once after program start, when pressing Ctrl+A in a tableviewer to select all entries. Despite the message, the entires are selected. The errors occurs on both Windows and Linux. When targeting 4.7(.1?) no such messages are logged.
(In reply to Benjamin Brandl from comment #33) > Created attachment 274747 [details] > Trace > > I'm not sure whether this is releated, but since switching the target to > Eclipse 4.8, I'm seeing exceptions like: > > org.eclipse.e4.core.di.InjectionException: > org.eclipse.core.commands.NotHandledException: Handler > org.eclipse.ui.internal.handlers.SelectAllHandler@72f86029 is not handled > for for command Command(org.eclipse.ui.edit.selectAll,Alles auswählen, > Alles auswählen, > Category(org.eclipse.ui.category.edit,Bearbeiten,null,true), > org.eclipse.ui.internal.WorkbenchHandlerServiceHandler@28e12bc5, > ,,true) > > A full stacktrace can be seen in the attachment. > > The exception occurs only once after program start, when pressing Ctrl+A in > a tableviewer to select all entries. Despite the message, the entires are > selected. The errors occurs on both Windows and Linux. > > When targeting 4.7(.1?) no such messages are logged. This is related to this bug, see https://git.eclipse.org/c/platform/eclipse.platform.ui.git/commit/?id=b140def30122a542a8b23ae952eec4b88e1eaf7f I've added error to identify cases where not executed command is silently ignored. Most likely something is wrong with the way you define the command in the table viewer? Please if you can reproduce it with plain SDK, report a new bug for it.
Created attachment 274850 [details] new trace with broken Java editor Just encountered in 4.9 again, I did nothing special, just wa constantly running a small java app in debugger and changed the code for that. For some reason Ctrl+D stopped to work. Enabling the tracing shows that the handler was not found ?!? | main | 2018-07-06 10:01:06.233 | org.eclipse.e4.ui.workbench | /trace | org.eclipse.e4.ui.internal.workbench.WorkbenchLogger | trace | 159 | Command ParameterizedCommand(Command(org.eclipse.ui.edit.text.delete.line,Delete Line, Delete a line of text, Category(org.eclipse.ui.category.textEditor,Text Editing,Text Editing Commands,true), org.eclipse.ui.internal.WorkbenchHandlerServiceHandler@6bd8beab, ,,true),null), defined: true, handled: false in context chain: WorkbenchContext -> TrimmedWindowImplContext -> PerspectiveImpl (org.eclipse.jdt.ui.JavaPerspective) Context -> PartImpl (org.eclipse.e4.ui.compatibility.editor) org.eclipse.jdt.ui.CompilationUnitEditor removeOnHide activeOnClose (Snippet.java) Context | | main | 2018-07-06 10:01:06.233 | org.eclipse.e4.ui.workbench | /trace | org.eclipse.e4.ui.internal.workbench.WorkbenchLogger | trace | 159 | Command exception for: ParameterizedCommand(Command(org.eclipse.ui.edit.text.delete.line,Delete Line, Delete a line of text, Category(org.eclipse.ui.category.textEditor,Text Editing,Text Editing Commands,true), org.eclipse.ui.internal.WorkbenchHandlerServiceHandler@6bd8beab, ,,true),null) in context chain: WorkbenchContext -> TrimmedWindowImplContext -> PerspectiveImpl (org.eclipse.jdt.ui.JavaPerspective) Context -> PartImpl (org.eclipse.e4.ui.compatibility.editor) org.eclipse.jdt.ui.CompilationUnitEditor removeOnHide activeOnClose (Snippet.java) Context | org.eclipse.core.commands.NotHandledException: There is no handler to execute for command org.eclipse.ui.edit.text.delete.line at org.eclipse.core.commands.Command.executeWithChecks(Command.java:507) at org.eclipse.core.commands.ParameterizedCommand.executeWithChecks(ParameterizedCommand.java:487) at org.eclipse.e4.core.commands.internal.HandlerServiceImpl.executeHandler(HandlerServiceImpl.java:204) at org.eclipse.e4.ui.bindings.keys.KeyBindingDispatcher.executeCommand(KeyBindingDispatcher.java:305) What also interesting is: after editor was closed and re-opened, it worked, but the activation trace shows a different context name and state. The broken editor was showing following during activation: | main | 2018-07-06 09:59:14.814 | org.eclipse.e4.ui.workbench | /trace/focus | org.eclipse.e4.ui.internal.workbench.Activator | trace | 158 | Activation done: org.eclipse.e4.ui.compatibility.editor=org.eclipse.e4.ui.model.application.ui.basic.impl.PartImpl@370c1968 (tags: [Editor, org.eclipse.jdt.ui.CompilationUnitEditor, removeOnHide, active], contributorURI: null) (widget: ContributedPartRenderer$1 {}, renderer: org.eclipse.e4.ui.workbench.renderers.swt.ContributedPartRenderer@40c0437f, toBeRendered: true, onTop: false, visible: true, containerData: null, accessibilityPhrase: null) (contributionURI: bundleclass://org.eclipse.ui.workbench/org.eclipse.ui.internal.e4.compatibility.CompatibilityEditor, object: CompatibilityPart [partId=org.eclipse.e4.ui.compatibility.editor, properties=[], tags=[Editor, org.eclipse.jdt.ui.CompilationUnitEditor, removeOnHide, active], wrapped=class org.eclipse.jdt.internal.ui.javaeditor.CompilationUnitEditor, legacyPart=class org.eclipse.jdt.internal.ui.javaeditor.CompilationUnitEditor, beingDisposed=false, alreadyDisposed=false], context: PartImpl (org.eclipse.e4.ui.compatibility.editor) org.eclipse.jdt.ui.CompilationUnitEditor removeOnHide activeOnClose (Snippet.java) Context, variables: [], label: Snippet.java, iconURI: platform:/plugin/org.eclipse.jdt.ui/icons/full/obj16/jcu_obj.png, tooltip: null, dirty: false, closeable: true, description: null) | The working editor was showing following during activation: | main | 2018-07-06 10:07:31.859 | org.eclipse.e4.ui.workbench | /trace/focus | org.eclipse.e4.ui.internal.workbench.Activator | trace | 158 | Activation done: org.eclipse.e4.ui.compatibility.editor=org.eclipse.e4.ui.model.application.ui.basic.impl.PartImpl@4e79f3ea (tags: [Editor, org.eclipse.jdt.ui.CompilationUnitEditor, removeOnHide, active], contributorURI: null) (widget: ContributedPartRenderer$1 {}, renderer: org.eclipse.e4.ui.workbench.renderers.swt.ContributedPartRenderer@40c0437f, toBeRendered: true, onTop: false, visible: true, containerData: null, accessibilityPhrase: null) (contributionURI: bundleclass://org.eclipse.ui.workbench/org.eclipse.ui.internal.e4.compatibility.CompatibilityEditor, object: CompatibilityPart [partId=org.eclipse.e4.ui.compatibility.editor, properties=[], tags=[Editor, org.eclipse.jdt.ui.CompilationUnitEditor, removeOnHide, active], wrapped=class org.eclipse.jdt.internal.ui.javaeditor.CompilationUnitEditor, legacyPart=class org.eclipse.jdt.internal.ui.javaeditor.CompilationUnitEditor, beingDisposed=false, alreadyDisposed=false], context: PartImpl (org.eclipse.e4.ui.compatibility.editor) org.eclipse.jdt.ui.CompilationUnitEditorContext, variables: [], label: Snippet.java, iconURI: platform:/plugin/org.eclipse.jdt.ui/icons/full/obj16/jcu_obj.png, tooltip: null, dirty: false, closeable: true, description: null) | The difference is in the context *name* and tags on the "legacyPart": BAD: context: PartImpl (org.eclipse.e4.ui.compatibility.editor) org.eclipse.jdt.ui.CompilationUnitEditor removeOnHide activeOnClose (Snippet.java) Context, variables: [] GOOD: context: PartImpl (org.eclipse.e4.ui.compatibility.editor) org.eclipse.jdt.ui.CompilationUnitEditorContext, variables: [] Why do we see such a difference???
The activeOnClose tag in particular is strange. After checking, it is EPartService.ACTIVE_ON_CLOSE_TAG, and its added to a part on *shutdown*. Its then removed on the next start-up and the part which had the tag receives focus. The code which removes the tag on start-up is rather optimistic and doesn't report problems if there are more than 1 parts with this tag; it merely removes the tag of the first (only this one will be focused). In theory there can be only 1 part with a tag anyway. I find no other use for the tag, but if the workbench close and start-up logic broke, who knows what else broke.
Never mind, I checked the calls to PartImpl.setContext(). The difference outlined in comment 35 comes from re-opening the editor. If an editor was active at Eclipse shutdown, it will have a context as seen in the "bad" case. If its re-opened after the new start, it will have a context as seen in the "good" case. I don't think the difference in context activation traces is relevant for the bug.
New Gerrit change created: https://git.eclipse.org/r/128735
I've created https://git.eclipse.org/r/#/c/128735/, which adds the command handler to the tracing infos. I've also observed that the context which is printed by the infos is not accurate. The context string representation is computed *at creation* and is later on returned by EclipseContext.toString(). This means, its not clear what exactly the current contents of the model part are (e.g. tags); its only known what they *were* at context creation time. This is why when closing and opening an editor the context shows no tags; the new context is created before tags are added to the editor part. I've also noticed that usually there is an "active" tag present in the editor part, whenever a command is executed. This is not seen in the tracing from the bad case listed by Andrey. Whether this is due to a bug, or due to EclipseContext.toString() "snapshots" at the wrong time, I don't know. The active tag is stored by SWTPartRenderer.styleElement(), on focus/selection events from SWT. If the tag really is missing, maybe there is some odd state of GTK having focus but platform UI not knowing about it.
Gerrit change https://git.eclipse.org/r/128735 was merged to [master]. Commit: http://git.eclipse.org/c/platform/eclipse.platform.ui.git/commit/?id=c967973f50119c66e7b2ddd3f8e225922298d396
(In reply to Eclipse Genie from comment #40) > Gerrit change https://git.eclipse.org/r/128735 was merged to [master]. > Commit: > http://git.eclipse.org/c/platform/eclipse.platform.ui.git/commit/ > ?id=c967973f50119c66e7b2ddd3f8e225922298d396 Please update (bump service segment) org.eclipse.e4.ui.bindings bundle. We are in 4.10 now.
> Please update (bump service segment) org.eclipse.e4.ui.bindings bundle. We > are in 4.10 now. In this case, I should only implement the micro/third segment, right? Just not sure whether some specific rules for versioning additionally to semver have been kept with the single stream model.
(In reply to Mickael Istria from comment #42) > > Please update (bump service segment) org.eclipse.e4.ui.bindings bundle. We > > are in 4.10 now. > > In this case, I should only implement the micro/third segment, right? Correct. Add 100 to the third/ service segment. See here: https://wiki.eclipse.org/Version_Numbering#When_to_change_the_service_segment
(In reply to Lars Vogel from comment #43) > Correct. Add 100 to the third/ service segment. See here: > https://wiki.eclipse.org/Version_Numbering#When_to_change_the_service_segment So we keep the legacy versioning patterns for multiple streams although we now havr.only one stream? I'll do that, but it seems like there is room for simplification here.
(In reply to Mickael Istria from comment #44) > So we keep the legacy versioning patterns for multiple streams although we > now havr.only one stream? > I'll do that, but it seems like there is room for simplification here. Please bring any process improvement idea to the PMC mailing list or ask Alex to present it in the PMC call. I would love to get rid of this work.
(In reply to Mickael Istria from comment #44) > (In reply to Lars Vogel from comment #43) > > Correct. Add 100 to the third/ service segment. See here: > > https://wiki.eclipse.org/Version_Numbering#When_to_change_the_service_segment > > So we keep the legacy versioning patterns for multiple streams although we > now havr.only one stream? > I'll do that, but it seems like there is room for simplification here. If platform does not have maintenance stream it does not mean in-house maintenance streams aren't used. I would say simplification here is not good.
(In reply to Andrey Loskutov from comment #41) > (In reply to Eclipse Genie from comment #40) > > Gerrit change https://git.eclipse.org/r/128735 was merged to [master]. > > Commit: > > http://git.eclipse.org/c/platform/eclipse.platform.ui.git/commit/ > > ?id=c967973f50119c66e7b2ddd3f8e225922298d396 > > Please update (bump service segment) org.eclipse.e4.ui.bindings bundle. We > are in 4.10 now. Simeon, please watch your bugzilla mails. I will push the change.
Gerrit change https://git.eclipse.org/r/129361 was merged to [master]. Commit: http://git.eclipse.org/c/platform/eclipse.platform.ui.git/commit/?id=44791e632aa7990bd06cb7af6849b61b561539d0
*** Bug 542081 has been marked as a duplicate of this bug. ***
I haven't seen this bug for quite some time, may be we've managed to fix something somewhere => closing. If anyone on the CC list still observing the issue with latest 2018-12 (4.10) release or nightly builds of 4.11, feel free to reopen.
