Community
Participate
Working Groups
Broken in 4.2.2 and in 4.3; works fine 3.8.2. Probably a similar reason as bug 411602. - open a text editor - open a dialog with a "?" (Help) button (e.g. About Eclipse) and click the "?" - click a link to get to an HTML page - click into the Browser widget - press Ctrl+F => the keystroke is wrongly processed by the workbench window. Find/Replace dialog is opened in the workbench window (behind the dialog). Can also be reproduced in a persisted Javadoc hover (F2).
> Probably a similar reason as bug 411602. The fix for bug 411602 did not fix this bug here.
Grant, can you think of any reason I'm getting a KeyDown event on windows (I guess from IE) but not on linux (from FF)? PW
Pushed fix (on master/4.4) to Gerrit for review: https://git.eclipse.org/r/18228 The ShellActivationListener's deactivate handler incorrectly assumed that if a dialog is deactivated, then the previously active context (e.g. the workbench window) must be active. But, in the case of Ctrl+F, a browser-supplied dialog is active. Re-activating the workbench window enables Ctrl+F to also be handled there. In my testing, the removed branch of code in ShellActivationListener was only ever hit when a dialog has lost focus. In the case of the dialog closing, other mechanisms were already re-activating the previously active context(s). Tested a deactivating dialogs and modeless dialogs in a number of other scenarios, and the removed code was never necessary -- the activation of another window in the application was always detected.
(In reply to Paul Elder from comment #3) > Pushed fix (on master/4.4) to Gerrit for review: > > https://git.eclipse.org/r/18228 My testing couldn't reproduce the problem on linux, but all the tests pass so I've recommended Eric review the patch as well. I found Bug 421574 during testing. PW
Bug 413977 is very similar, but the fix here has no impact on that bug :-(
(In reply to Paul Elder from comment #3) > Pushed fix (on master/4.4) to Gerrit for review: > > https://git.eclipse.org/r/18228 Released as http://git.eclipse.org/c/platform/eclipse.platform.ui.git/commit/?id=5db9936fcbc271f94ecb22aababc118153503e72 PW
Paul, I've patched back the fix as https://git.eclipse.org/r/#/c/18520/ for review. PW
Looks good. Release on R4_3_maintenance as: https://git.eclipse.org/c/platform/eclipse.platform.ui.git/commit/?h=R4_3_maintenance&id=c2c6d962e852f5161395a0712161bbafa4e9fd78
I've updated the bundle version and copyright date with http://git.eclipse.org/c/platform/eclipse.platform.ui.git/commit/?id=06b6d9aacae41de5a4e6474eed87cd264fc37ff7 http://git.eclipse.org/c/platform/eclipse.platform.ui.git/commit/?id=6ea80cd33e929a2de6f3e791ce18db6eb0faf467
Verified in 4.3.0.M20131127-1300
This fix broke the Key Assist dialog on Linux, see bug 420742.
(In reply to Dani Megert from comment #11) > This fix broke the Key Assist dialog on Linux, see bug 420742. Reverted the changes for now (see bug 420742 comment 7). master: http://git.eclipse.org/c/platform/eclipse.platform.ui.git/commit/?id=ba0a149ee7a195a07c6b169f6d5ee6cdfcbcb022 R4_3m : http://git.eclipse.org/c/platform/eclipse.platform.ui.git/commit/?id=7986153921349b7e22a32f0d6e991077a71f8004
Pushed another attempt at a fix to master: https://git.eclipse.org/r/20724 Need to consider whether this still impacts bug 420742. Also, this fix appears to also fix bug 413977.
Released on master (4.4) as: https://git.eclipse.org/c/platform/eclipse.platform.ui.git/commit/?id=593fb6f2d714d40d6a09d14ed2eef00f1a212492
Marking as fixed on 4.4 M5. Cloned bug 426019 as a back port to 4.3.2
Verified in 4.4.0.I20140120-2000 on Win 7-64. Regressions from previous fixes (described in comment 11) tested on Mac OS X 10.9.1 and Unbuntu 12.04 (x86/64)
