Community
Participate
Working Groups
N2006040507-0010. From time to time I loose the key bindings in the Java editor. It is not bug 135514 since the damage is restricted to the editor where it happens and closing and re-opening normally fixes the problem. See also similar reports in bug 133594. The scenario where it sometimes happens is: - open a type using Ctrl+Shift+T - quickly press Ctrl+L (or invoke some other command that needs further input) to go to a line and enter the line number ==> Ctrl+L didn't work and line number is entered into the editor. Subsequent key bindings are lost, e.g. Ctrl+L or Ctrl+O no longer working. I work with multiple windows.
Paul, maybe you could comment here on what trace options should be turned on by the people encountering this problem. I have the following options turned on, but I'm not sure if these are the exact ones you would recommend: org.eclipse.ui/trace/keyBindings=true org.eclipse.ui/trace/sources=true org.eclipse.ui/trace/handlers=true org.eclipse.ui/trace/handlers.verbose=true org.eclipse.ui/trace/contexts=true org.eclipse.ui/trace/contexts.verbose=true
Good point, john. org.eclipse.ui/debug=true org.eclipse.ui/trace/keyBindings=true org.eclipse.ui/trace/keyBindings.verbose=true org.eclipse.ui/trace/sources=true org.eclipse.ui/trace/handlers=true org.eclipse.ui/trace/handlers.verbose=true org.eclipse.ui/trace/contexts=true org.eclipse.ui/trace/contexts.verbose=true If I also have a specific command I know is working then not working (like F3) I also add: org.eclipse.ui/trace/commands=true org.eclipse.ui/trace/handlers.verbose.commandId=org.eclipse.jdt.ui.edit.text.java.open.editor PW
I was able to get into a no-handler state on Linux-GTK+ by using key shortcuts and swapping between multiple windows. Still Investigating ... PW
I can reproduce the problem if I have 2 windows open. One with the Java and Debug perspective and one with the Java and CVS Repository Exploring perspective. If I switch between the windows, Debug in one and Java in the other, CTRL+F6 continues to work. If I switch one window to the CVS perspective I lose all my handlers. HANDLERS >>> Unresolved conflict detected for 'org.eclipse.ui.window.nextView' HANDLERS >>> Unresolved conflict detected for 'org.eclipse.ui.navigate.back' HANDLERS >>> Unresolved conflict detected for 'org.eclipse.ui.file.revert' ... which then leads to: COMMANDS >>> execute >>> not handled: id=org.eclipse.ui.window.nextEditor; exception=org.eclipse.core.commands.NotHandledException: There is no handler to execute. PW
Created attachment 38014 [details] debug trace of 2 windows plus switch to CVS perspective
Created attachment 38081 [details] Debug trace with 2 windows and N0407 On my XP box I get different event ordering ... the shell is always made active, then the parts, then the command finishes. On Linux I got the parts active and the command finished, then the shell became active. PW
With N20060409-0010 it seems trivial to break the keybindings with 2 windows open. I'm on Linux=GTK+. But clicking on the chevron and selecting another editor seems to fix the problem. PW
Indeed: switching to another editor and back to the "broken" one seems to restore the key bindings.
Created attachment 38093 [details] Event tracing by the numbers The first ALT+TAB gives 2 shell activations, one that's no good, followed by an OK one. The second ALT+TAB gives 1 shell activation that's no good. It never shows the activation of the new shell. PW
Created attachment 38211 [details] Handler trace output when in broken state
John, I've added more verbose handler tracing output that would hopefully show me the loser in a handler conflict resolution. Could you work with the N20060411 build tomorrow? Later, PW
Created attachment 38847 [details] Handler trace output on N20060418 Happened again. Trace output attached. I was opening the context menu alot to chose revert. I.e., I was doing something like: 1) Type in editor 2) Select revert from context menu 3) Repeat 1-2 quickly a few times 4) Ctrl+O to open outline - noticed that key bindings were busted
>3) Repeat 1-2 quickly a few times I think the key here is "quickly". I also see it mostly when I e.g. open a type and then quickly invoke a command, e.g. Ctrl+L.
There's a context I haven't been able to track down, it seems to be generating the BINDINGS >>> NotDefinedException('Cannot get the parent identifier from an undefined context.') while filtering dialog/window contexts CONTEXT: org.eclipse.pde.ui.RuntimeWorkbench.org.eclipse.debug.ui.DebugPerspective PW
org.eclipse.debug.internal.ui.launchConfigurations.PerspectiveManager is adding contexts that look like org.eclipse.pde.ui.RuntimeWorkbench.org.eclipse.debug.ui.DebugPerspective on line 367: Context context = contextServce.getContext(type + "." + ids[i]); //$NON-NLS-1$ If the contexts are created in code, they should also be defined (that gives them a parent context as well). John, did you have the debug perspective open? I think this is causing us to fail in our recomputeBindings() ... I'm going to see if we can log NotDefinedException() and keep going. PW
>John, did you have the debug perspective open? Can't speak for John but I always have the Debug perspective open in a separate workbench window.
(In reply to comment #12) > 2) Select revert from context menu John, do you use CTRL+F10 or SHIFT+F10 to get to the context menu? PW
Released some better logging for the NotDefinedException case >20060423 PW
> John, do you use CTRL+F10 or SHIFT+F10 to get to the context menu? No.
>Released some better logging for the NotDefinedException case >20060423 1) if I understood our chat correctly, you also fixed that this scenario corrupts the key bindings. 2) the logging might have to be made smarter: the .log gets swamped because the same exception is logged very often.
I've added an optimization to the error logging. It will only log the first occurrance of the NotDefinedException for any given context ID. Released >20060424 PW
Not fixed yet: using N20060425-0010 which has the fix for bug 138220 and which indeed no longer causes NotDefinedException I still loose the key bindings.
Dani, could I get you to run with some debug options? org.eclipse.ui/debug=true org.eclipse.ui/trace/keyBindings=true org.eclipse.ui/trace/keyBindings.verbose=true org.eclipse.ui/trace/sources=true org.eclipse.ui/trace/handlers=true org.eclipse.ui/trace/handlers.verbose=true org.eclipse.ui/trace/contexts=true org.eclipse.ui/trace/contexts.verbose=true pipe it to a file, and when you lose keybindings mark the point in the file and attach it to the bug. You work on Windows XP, corret? Thanx, PW
>Dani, could I get you to run with some debug options? Sure. >You work on Windows XP, corret? Yes.
Created attachment 39559 [details] key trace info I got it again. The incident happens towards the bottom of the attached log.
Created attachment 39562 [details] Trace of last events (keybindings don't work at end) N20060426-0010, WinXP, JDK1.5.0_06 I was debugging and I think my last action was a Ctrl+Click on a type name that opened a new Java editor. In the editor, DEL worked, but Ctrl+Left, Ctrl+Right, Alt+Shift+J, etc. didn't work. Switching to another application did not make keybindings work again, but switching to another editor in Eclipse did. Unfortunately, I could not reproduce after it started to work again.
Markus, Dani, do you have any more of your log? Even if you mail it to me, that would be helpful. ex: Markus, in your log I can see where org.eclipse.ui.edit.text.goto.wordNext is set to no handler, but I can't see the changes above that HANDLERS trace (that would include CONTEXTS, SOURCES, and KEYS) that kicked off the handler being nulled out. I'm going to investigate why we're providing a LegacyHandlerSubmission for so many actions while they're obviously provided by subactionbars at the partsite level. Later, PW
No, that's all. I should have piped that stuff into a file.
Created attachment 39635 [details] Trace of lost key binding I did 'Ctrl-Shift-T' and opened 'CleanUpTest.java' which worked fine and then 'Ctrl-O' which did not work anymore.
Created attachment 39637 [details] Trace of found key bindings Mmm, now it works again, not sure what I did though... I've opened AssistQuickFixTest in the previous trace, but I don't think that this matters.
>Mmm, now it works again, not sure what I did though... They aren't completely lost. As soon as you switch to another editor or open a new one they are restored (even for the editor where it was broken).
(In reply to comment #29) > > I did 'Ctrl-Shift-T' and opened 'CleanUpTest.java' which worked fine and then > 'Ctrl-O' which did not work anymore. What version of eclipse are you on? Are you on Linux-GTK+ with a gtk2 version of less than 2.6.8? Also, I need the logs from 2 KEYS points ... i.e. from a KEYS trace that works to a KEYS trace that doesn't, or the other way around. Later, PW
OK, here's a full debug trace (can't attach due to bugzilla limitation): http://dev.eclipse.org/viewcvs/index.cgi/%7Echeckout%7E/platform-text-home/3.2/misc/bug135535_log.zip Checkout the "KEYS >>> not handled" at the end of the file.
Thanx, Dani, that's a good log. PW
Created attachment 40028 [details] Extra debugging for commands This extra debugging will log stack traces when command handlers are reset. It should be targetted at a specific command, since it'll generate a lot of output. org.eclipse.ui/debug=true org.eclipse.ui/trace/keyBindings=true org.eclipse.ui/trace/keyBindings.verbose=true org.eclipse.ui/trace/sources=true org.eclipse.ui/trace/handlers=true org.eclipse.ui/trace/handlers.verbose=true org.eclipse.ui/trace/handlers.verbose.commandId=org.eclipse.jdt.ui.edit.text.java.show.outline org.eclipse.ui/trace/contexts=true org.eclipse.ui/trace/contexts.verbose=true PW
Note that if you install the patched jars, you have to delete the original jars for ui.workbench and core.commands. Also, make sure you use the updated options file because otherwise there is just too much output.
Sorry, I just realized that the patched jars were not attached to this bug. Unfortunately, bugzilla does not allow attachments of more than two megs, so I'm sending as an e-mail to Daniel. If anybody else wants to try their luck reproducing this, please send me an e-mail and I can send you the patched jars.
Created attachment 40073 [details] Extra debugging for commands v03 This contains some more detailed debugging for the java outline command, CTRL+O PW
Created attachment 40085 [details] Extra debugging for commands v04 Switched the field around to stop getting exceptions. PW
Created attachment 40106 [details] Extra debugging for commands v05 Added the site and shell trace information plus a forced re-evaluation. PW
Boris, I marked an activation to show when it was set. This failure only has proper evaluations, never a setResult(*) "activation-set" ... so it's not shadowing a cache that's being incorrectly set. HANDLERS >>> found matching handler activation: HandlerActivation(commandId=org.eclipse.jdt.ui.edit.text.java.show.outline,handler=LegacyHandlerWrapper(ActionHandler(action=org.eclipse.ui.texteditor.TextOperationAction@ec15ce)),expression=LegacyHandlerSubmission(Shell {Java - ImageLabelProvider.java - Eclipse SDK},null,PartSite(id=org.eclipse.jdt.ui.CompilationUnitEditor,pluginId=org.eclipse.jdt.ui,registeredName=Java Editor)),sourcePriority=67113984) HANDLERS >>> activation-eval: Wed May 03 07:40:43 EDT 2006 activation-set: null activation-clean: null HANDLERS >>> last evaluate used shell: Shell {Java - ImageLabelProvider.java - Eclipse SDK} site: PartSite(id=org.eclipse.jdt.ui.CompilationUnitEditor,pluginId=org.eclipse.jdt.ui,registeredName=Java Editor) HANDLERS >>> matching handler activation evaluates to: false HANDLERS >>> current context shell: Shell {Java - ImageLabelProvider.java - Eclipse SDK} shell-match: true HANDLERS >>> current context site: PartSite(id=org.eclipse.jdt.ui.CompilationUnitEditor,pluginId=org.eclipse.jdt.ui,registeredName=Java Editor) site-match: true HANDLERS >>> forced evaluation: true PW
Created attachment 40193 [details] Extra debugging for commands v06 Latest debugging info with timestamps PW
Created attachment 40201 [details] Extra debugging for commands v07 Fix NPE in tracing patch. PW
Created attachment 40299 [details] Extra debugging for commands v08 Extra debugging, it also prints handler evaluations at their source priorities. Even on windows PW
Just let us know if you need us to run on your instrumented code. As far as I understood Boris, you were able to reproduce it as well.
Created attachment 40316 [details] Recreated on a self-hosted eclipse This is log with the latest debugging. The activation we're tracing is tied to hashCode=3127917 There's some weird behaviour, where a resolveConflicts seems to choose one handler, and the the actual updateHandler shows another one being set. PW
(In reply to comment #46) > There's some weird behaviour, where a resolveConflicts seems to choose one > handler, and the the actual updateHandler shows another one being set. The log is good, but this anomaly is a bug in the updateHandler() reporting. PW
Created attachment 40390 [details] Trace of lost bindings on I20060504-1208 It happened immediately after startup so I thought it worth posting the trace. I didn't have any of the above patches installed.
Thanks John! Just to give you a status update - over lunch, we finally found something concrete that might cause this.
Created attachment 40407 [details] Trace of lost key bindinings in N20060504-0010 using patched ui.workbench
*** Bug 140246 has been marked as a duplicate of this bug. ***
Created attachment 40454 [details] patch 09 prints "GOTCHA" when the bug is encountered and outputs all activationhandlers with their current evaluation result and the stack trace of the time they were evaluated.
Created attachment 40455 [details] trace when running with patch 09 Paul, as we suspected, the activation handlers are evaluated at different times, sometimes leading to different results. Have a look at this trace - some of the activation handlers are evaluated as a reaction to firePartDeactivated (ends up in sourceChanged, evaluation result is true), and others are evaluated upon activation (ends up in activateHandler, evaluation result is false). What you can see in the trace is a true-true case.
Created attachment 40456 [details] first attempt at fixing this This is the fix we talked about: force an evaluation of all existing activation handlers before adding a new one in HandlerAuthority.activateHandler(). Unfortunately, I am not sure what the consequences of this fix are with regards to performance. To all interested parties, especially Daniel: If possible, please work with this patch and check if this fixes the bug. Should you notice performance problems, please let us know. McQ, is it possible to schedule a performance test run to see how bad this is? (Note that the patch is not released to HEAD at this point.)
Please provide a patched plug-in. I don't have Plat UI in source.
I was thinking about this, and I think we need to re-evaluate in source changed ... just re-doing the activation earlier would switch our activation to true, but wouldn't re-evaluate the active handler. PW
Paul, was it intended to remove the '3.2' target?
Ooops, no :-) I was able to replicated the problem with an extra exception. The results seemed to imly that the true-true guy had his result cache cleared before sourceChanged somehow. final boolean currentActive = evaluate(activation); activation.clearResult(); final boolean newActive = evaluate(activation); My trace showed that the activation was thoroughly evaluated for both currentActive and newActive. Maybe another class is calling clearResult() on the handler activation for some reason. PW
Created attachment 40470 [details] proof of concept fix v02 This is a proof of concept fix. If the first activation has been updated before the others in the expression set, then it denotes no change and the other handlers aren't updated. Dani, I'll send you the patched workbench plugin. If you could run with this for a while. PW
+1. fix makes sense to me.
(This was written when bugzilla was down, so McQ's +1 is a reaction to this:) McQ, JohnA, Jeff - could you review the patch (the one called "proof of concept fix v02") and approve for RC3? I believe the fix is good - I'll try to explain: For each abstract command (e.g. Quick Outline, with the id "org.eclipse.jdt.ui.edit.text.java.show.outline"), there is one instance of Command. The actual code that executes when the command is run is in an IHandler instance. The current handler for a command is determined based on core expressions that describe their activation, based on the current active editor id, or the active editor site, the active shell, and so on. The abstraction that provides access to these values (current active editor etc.) is called IEvaluationContext. Given an IEvaluationContext, you can evaluate activation expressions. The results of such evaluations are cached in instances of HandlerActivation. Now whenever the current evaluation context has changed (e.g., another editor became active), affected caches need to be cleared or recalculated. The code for this is in HandlerAuthority.sourceChanged. The code in sourceChanged looks at all expressions whose values could potentially change. The parameter "sourcePriority" is really a bit mask (see constants in ISources) that describes which aspects in the context have changed. For each bit in the bit mask, we look at all expressions whose values may be affected by the change described by the bit. In particular, we get the HandlerActivation objects that share the same expression. For the first one of these objects (remember it holds a cached evaluation result), we look at the cached value (we know that it must have a cached value) and force a re-evaluation using the current evaluation context. If the value changed, the corresponding command's handler needs to be updated, and we need to do the same for all other HandlerActivation objects sharing the same expression. There is no need to re-evaluate the expressions for the other HandlerActivation objects because they all share the same expression, and use the same current context, so we can just set their cached values. If you were able to follow so far, here is the bug - if the value of the first HandlerActivation object did not change, we don't look at the remaining HandlerActivation objects with the same expression. I guess the intuition was that their cached values should all match, but this is not always true since they might have been evaluated at different times, using different evaluation contexts. The fix is to iterate over the remaining HandlerActivation objects and compare their cached result to the current result ("newActive"). If we find a cached value that is different from the current result, its value is set to the current result, and the handler of the corresponding command will be updated. The bug is so hard to reproduce because which HandlerActivation object is looked at first depends on hash codes (they are held in a HashSet). For most of the HandlerActivation objects in that set, the bug would not appear.
+1 The patch in comment #59 has been released for the 11am EDT 3.2 RC3 candidate build.
For the record, here is how I usually reproduced the bug (it does take some time): Open multiple workbench windows, with multiple editors in each opened using Ctrl-Shift-T, and switch between editors using different means. In each editor that you activate, you press Ctrl-O for the quick outline. You found the bug if Ctrl-O does not work. Usually, when this happens there are other key bindings that stop working as well.
I can't believe this hadn't already been marked as a great bug. Dani added value and action not just by reporting this and describing how he reproduced it, but by repeatedly testing fixes and sending back debug traces over the past month as this bug was narrowed down. Somebody get this man a T-shirt!
Marking as fixed.
Thanks guys! So far the provided patch worked out.
*** Bug 140459 has been marked as a duplicate of this bug. ***
*** Bug 137091 has been marked as a duplicate of this bug. ***
verified in RC4 PW
