Bugzilla – Full Text Bug Listing
| Summary: | [KeyBindings] Bindings stop working (no shell activation event) | ||||||||
|---|---|---|---|---|---|---|---|---|---|
| Product: | [Eclipse Project] Platform | Reporter: | Jared Burns <jared_burns> | ||||||
| Component: | UI | Assignee: | Douglas Pollock <douglas.pollock> | ||||||
| Status: | VERIFIED FIXED | QA Contact: | |||||||
| Severity: | major | ||||||||
| Priority: | P1 | CC: | billy.biggs, daniel_megert, michaelvanmeekeren | ||||||
| Version: | 3.1 | ||||||||
| Target Milestone: | 3.1 RC1 | ||||||||
| Hardware: | PC | ||||||||
| OS: | Linux-GTK | ||||||||
| Whiteboard: | |||||||||
| Attachments: |
|
||||||||
|
Description
Jared Burns
Looks like bug 95276. - is the browser widget active (Help, Javadoc view) - anything in .log? Not sure whether this is related but I just found this bug: 1. make sure Help view is closed 2. set focus to editor (see tab is blue) 3. open the Help view via Window > Show View 4. click into editor (text area, not the tab) ==> editor tab stays white and actions aren't retargeted (disabled in menus and commands don't work) Even more bad things happen with the Help view (after step 3 in comment 2): - the editor still has the input focus - if I open the context menu the one for the editor is opened After step 4 in comment 2 give the focus to the editor by clicking on the tab and press Ctrl+F7 and we're back into the same trouble. Those findings are on Windows XP, N20050517-0010. Javadoc view behaves fine in that scenario. Jared, is the Help view open in your workbench window? If so, can you reproduce this bug once the Help view is closed? Okay, Dani please file a separate bug if you feel something else is going on. Billy and I pulled out a kludge for Bug 56231 a month or two ago. Since then, these intermittent failures have been possible. It is a race condition between a workaround for a bug in GTK+ and the window manager. We now have confirmed that it is possible to make a situation in which a shell activation event will not be sent when a dialog closes. All of the key binding code is dependent on the shell activation events, and so this can cause the key bindings to stop working. I believe the situation is recreatable with the following conditions: 1.) Mouse pointer is over the main Eclipse window 2.) Use the keyboard to open and close a dialog 3.) Get (un)lucky on the timing of certain focus events We will likely be putting the kludge back in place. The kludge is simply to take the shell on which a key binding arrives as the active shell. If it does not correspond to our current internal state of the world, we update our internal state to match. The symptoms for this bug are: 1.) Some or all of the key bindings in the menus will appear correctly 2.) No key bindings will work 3.) Clicking around in the workbench window will not restore sanity 4.) Switching to another shell and back to the workbench window will restore sanity 5.) Mnemonics will continue to work 6.) Typing in the focus control (i.e., native widget keyboard behaviour) will still work I have opened Bug 95569 to describe a different technical problem that can be triggered by similar steps. I have opened Bug 95575 to cover a better (but riskier) way of solving this problem in SWT itself. MVM: I would like to commit a patch to workaround this problem in SWT. Created attachment 21263 [details]
Patch to "org.eclipse.ui.workbench"
The ugly kludge patch (first version). I think some further refinement might
help the performance of this patch.
I filed bug 95581 against Platform Help for the problems reported in comment 2 and comment 3 which I added here since, before comment 4, it was not clear that this was a Linux-GTK only bug. Just to confirm: this bug (and the related code) has no effect on any other Platform i.e. bug 95276 cannot be related to this in any way? There are symptoms are there are problems. Unfortunately, with key bindings sometimes there can be very similar symptoms caused by radically different problems. I'm taking this bug to be the problem described in comment #4, as this most closely matches the description. The problem described in comment #4 occurs only on GTK+. To answer Dani's question in comment #3, no, I never open the Help view. This was occurring during my normal development, so Doug's scenario is entirely possible. I open the "Open Type" dialog using the keybinding (ctrl+shift+t) all the time. approve, please document the patch with the SWT bug so we can remove it in the future if possible Created attachment 21370 [details]
Patch to "org.eclipse.ui.workbench"
This is just a refinement of the patch which tries to isolate the crazy method
calls that WorkbenchKeyboard needs to make to specific method calls. These
method calls are then marked with the bug number and big "DO NOT USE" warnings
in their comments.
Fixed in CVS. Failed to reproduce this problem by hammering on the "ctrl+shift+t" and "esc" combo for a while. I20050526-1200 |