Community
Participate
Working Groups
I frequently do the following actions when browsing code: 1. F3 or Ctrl-Shift-T to open a class declaration 2. ^O to bring up a quick outline 3. <type chars> to bring up a particular method With 3.x I could do these actions quickly without waiting for the editor to open. With 4.x somehow the Quick Outline disappears and the characters I type type over the class name. In fact I find that I really need to pause and wait between steps (1) and (2). Otherwise it will seem to work (that is, the editor will open and the Quick Outline window pops up), but before I can type in any characters the Quick Outline window will disappear. I mentioned this to Remy on IRC, and he suspected the following: [13:51:10] <rcjsuen> I just tried that but looks like F3 took so long the Ctrl+O and the characters did nothing [14:21:53] <briandealwis> rcjsuen: Oops, sorry, got distracted. Did the ^O come up with the your characters? Or were the characters put into the editor instead? [14:28:49] <rcjsuen> briandealwis: no in this case Ctrl+O didn't happen [14:28:55] <rcjsuen> i think it got eaten while the progress dialog was up (processing F3)
I can reproduce the same on Windows 7. It looks like the the focus is stolen again asynchronously from the Quick Outline. This also affects any other action that takes focus, e.g. opening Find/Replace (Ctrl+F) is not working if invoked directly after opening a resource. This should be fixed for 4.1.1.
What is the easiest way to reproduce this problem? I don't think I'm doing this right. If I open a file and then immediately hit Ctrl+F and start typing, the text goes inside the editor even on 3.x.
(In reply to comment #2) > What is the easiest way to reproduce this problem? I don't think I'm doing this > right. > > If I open a file and then immediately hit Ctrl+F and start typing, the text > goes inside the editor even on 3.x. Strange. I see this too if I open a *.java file. But if I open a *.txt file I get the Find/Replace dialog and then it types in there. Try using Open Type and then Ctrl+O.
Eric, can this be targeted for 4.1.1?
(In reply to comment #1) > I can reproduce the same on Windows 7. It looks like the the focus is stolen > again asynchronously from the Quick Outline. Okay, I think I'm starting to see this. After 'Open Type' and then using Ctrl+O and spamming the keyboard, the file opens and the outline shows up briefly while taking input but it suddenly disappears shortly after and the spammed input starts going inside the editor, correct?
(In reply to comment #5) > (In reply to comment #1) > > I can reproduce the same on Windows 7. It looks like the the focus is stolen > > again asynchronously from the Quick Outline. > > Okay, I think I'm starting to see this. > > After 'Open Type' and then using Ctrl+O and spamming the keyboard, the file > opens and the outline shows up briefly while taking input but it suddenly > disappears shortly after and the spammed input starts going inside the editor, > correct? Yep.
(In reply to comment #6) > (In reply to comment #5) > > (In reply to comment #1) > > > I can reproduce the same on Windows 7. It looks like the the focus is stolen > > > again asynchronously from the Quick Outline. > > > > Okay, I think I'm starting to see this. > > > > After 'Open Type' and then using Ctrl+O and spamming the keyboard, the file > > opens and the outline shows up briefly while taking input but it suddenly > > disappears shortly after and the spammed input starts going inside the editor, > > correct? > > Yep. And if you don't type anything except Ctrl+O, you at least loose the Ctrl+O as the Outline immediately closes.
*** Bug 352149 has been marked as a duplicate of this bug. ***
Upon further investigation this bug is a manifestation of the same problem described by bug 352149. After the editor is opened the stack renderer captures the request to activate the tab folder (in the shared area) an enqueues an asynchronous request activate its selected part. The keybinding is filtered through and the dialog is opened, correctly taking in input from the keyboard. The asynchronous request is processed later and the activation of the part causes the dialog to be deactivated (and closed).
Fix pushed to R4_development. http://git.eclipse.org/c/platform/eclipse.platform.ui.git/commit/?h=R4_development&id=7b3e5c63ad78c46914637b876e449e308b202f77
*** Bug 345946 has been marked as a duplicate of this bug. ***
Problem solved for me. Thanks Remy!
(In reply to comment #12) > Problem solved for me. Thanks Remy! Also verified on my end with I20110809-2000 on Windows XP. Thanks for checking, Brian.
