Bugzilla – Full Text Bug Listing
| Summary: | [KeyBindings] Some key bindings do not work in Java editors | ||||||
|---|---|---|---|---|---|---|---|
| Product: | [Eclipse Project] Platform | Reporter: | Olivier Thomann <Olivier_Thomann> | ||||
| Component: | UI | Assignee: | Platform-UI-Inbox <Platform-UI-Inbox> | ||||
| Status: | RESOLVED FIXED | QA Contact: | |||||
| Severity: | major | ||||||
| Priority: | P1 | CC: | daniel_megert, eclipse, fraenkel, francois, gregoire.seguin, john.arthorne, markus.kell.r, mmgarrido, philippe_mulet, pombredanne, pwebster | ||||
| Version: | 3.2 | ||||||
| Target Milestone: | 3.2 RC1 | ||||||
| Hardware: | PC | ||||||
| OS: | Windows XP | ||||||
| Whiteboard: | |||||||
| Attachments: |
|
||||||
|
Description
Olivier Thomann
Can you run with with some debugging options (See the section "Debugging" in http://www.magma.ca/~pollockd/despumate/bindingsHowTo.html)? keyBindings=true keyBindings.verbose=true sources=true handlers=true handlers.verbose=true handlers.verbose.commandId=org.eclipse.ui.edit.delete Attach the results of the trace -- annotated with when the problem started occurring. Thanks. Olivier: Can try the patch suggested in https://bugs.eclipse.org/bugs/show_bug.cgi?id=131884#c35 as well? Olivier: Do you see this bug in I20060329-0010 or later? Not for now. I don't have good steps to reproduce. I enabled the tracing and since then, I didn't get it. I'm going to close this bug. If you reproduce it, please re-open. Using I20060330-0010, I got a case where I didn't get any key bindings in the debugger. Backspace still works, but F6, F7, Ctrl + Z, etc. don't work anymore. *** Bug 134074 has been marked as a duplicate of this bug. *** Grabbed the latest I-build (I20060330-2000), enabled the trace. Haven't noticed any issue so far, key bindings seem functional. Moving to major, as there are no clear steps to reproduce. I don't think this is preventing anyone from getting work done. Leaving as P1. I disagree. Once you are in the wacky mode, you need to restart. So this is at least critical. Losing key bindings in the middle of debugging can imply wasting a lot of time. As soon as I trace it, I cannot reproduce. I'll continue to monitor it. I also couldn't reproduce once enabling the trace. Seems to indicate some timing issue; as once tracing it slows down the IDE quite a bit. Don't know for others, but I use multiple windows, in case this would explain the symptoms. (In reply to comment #12) > Don't know for others, but I use multiple windows, in case this would > explain the symptoms. So, you have reproducible steps? Can you give them please? Unfortunately no, this was just an observation from my setup; in case it would indicate a common scenario. Usually it works for a while, and gradually disappear; until I exit/restart and keep going. I haven't seen it today, but had to restart more often than I wanted, so maybe I didn't reach the point of non return. This happened to me today using I20060331-1210. In my case Ctrl+O is the key binding that I noticed was broken. After closing + reopening the editor it was fine. *** Bug 135081 has been marked as a duplicate of this bug. *** Found a reproducible testcase which shows the following
KEYS >>> Listener.handleEvent(type = KeyDown, stateMask = 0x0, keyCode = 0x10000
0c, time = 478653277, character = 0x0)
KEYS >>> WorkbenchKeyboard.press(potentialKeyStrokes = [F3, ])
KEYS >>> WorkbenchKeyboard.executeCommand(commandId = 'org.eclipse.jdt.ui.edit.t
ext.java.open.editor', parameters = {})
KEYS >>> not handled
Open the Debug perspective.
Set a method breakpoint.
Open the breakpoint properties.
Enable condition.
Type something valid and hit OK.
Now keybindings don't work
*** Bug 135214 has been marked as a duplicate of this bug. *** This is right. I tried the same steps and I lost the key bindings. Backspace still work, but delete or F6 or F5 are lost. I am using N20060405-0010. Using the steps in comment #17 it seems that after going to the breakpoint property dialog, the HandlerAuthority doesn't receive any more update events from it's source and so it doesn't re-active the handler. Still investigating ... PW Created attachment 37942 [details]
BreakpointConditionEditor dispose
The BreakpointConditionEditor was disposing the global HandlerService, which is why the commands stopped working.
PW
Moving to JDT/Debug. Could it be possible that there are other calls to dispose the handler service? (In reply to comment #24) > Could it be possible that there are other calls to dispose the handler service? While I was at it I imported most of the source for JDT, PDE, and UI. This was the only call to IDisposable#dispose() that didn't match where the service was created. PW And while I never really mentioned it, the problem is resolved with the patch applied. PW Good catch Paul. Released the fix to the breakpoint condition editor. Is there any way to be sure this is only bug? Does it sound plausible that all of you were editing breakpoint conditions just before you lost your keybindings? I'm pretty sure this isn't the main problem. My scenario is often: Open a type using Ctrl+Shift+T and then quickly press Ctrl+L (or some other short cut) 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 but only for that editor. I have to close and reopen it. (In reply to comment #27) > Does it sound plausible that all > of you were editing breakpoint conditions just before you lost your > keybindings? No - I am certain that this happened to me several times without me editing breakpoint conditions. From what I remember, it usually happened when quickly switching editors using Ctrl+F6. I've extracted the BreakpointConditionEditor bug into bug 135514. Moving this bug back to Platform UI since several people loose key bindings without manipulating breakpoint properties. There was a multi-window shell bug that was fixed as part of bug 131884. Moving this to fixed. If you encounter losing keybindings, please open a new bug with your usecase. Later, PW >There was a multi-window shell bug that was fixed as part of bug 131884. Bug 131884 got marked fixed as follows: dpollock@acm.org 2006-03-29 11:22:15 Nice try! We see (and reported) the key binding problems using this weeks N-builds (note: newer builds than bug 131884 you mention). The scenarios are also still those reported in this bug e.g. if a command is invoked directly after switching to or opening an editor. This bug is clearly not fixed and it really is critical. Do you really need a new bug which is just a copy of this one? If so, let us know and we'll do so. The problem with this bug is that there are two different things reported in it: 1) key bindings completely gone and restart needed. This one is now captured in bug 135514 and is fixed in N20060407-0010 2) key binding gone for one editor. Closing and reopening the editor fixes the problem (see e.g. comment 15 and comment 28) Dani, please open the new bug, this one is a little too busy. Please place the version that you noticed the problem in and your usecase to reproduce (or what you were doing when you first noticed the problem). Also, if you could run a couple of tests with last night's midnight build and mention that in the new bug. After creating it to Platform UI, if you can assign it to me that would be great. Thanx, PW Filed bug 135535. I'm quite sure in my case (comment #15) that I wasn't editing breakpoint conditions. I'll keep an eye on it and comment in the new bug if it happens to me again. *** Bug 137518 has been marked as a duplicate of this bug. *** Should this be present in the currently RC build (I20060413-1718)? I just hit the same problem i.e after editing a breakpoints condition I loose all key bindings. Had opened Bug 137518 , but it was mentionned this was fixed. Downloaded another version (mentionned above) and it does not appear to be fixed in that version. |