Community
Participate
Working Groups
On M3 and almost certainly not reproducible. I was using a JDT editor, selected a tab to change edited file; the changed file appeared to be active. Tried doing some editing, but ^C and ^X and ^V all refused to do anything although typing worked fine. When I switched back to the previous editor I found that the ^V's had taken effect there instead!!!
(In reply to comment #0) > On M3 and almost certainly not reproducible. > > I was using a JDT editor, selected a tab to change edited file; the changed > file appeared to be active. Tried doing some editing, but ^C and ^X and ^V > all refused to do anything although typing worked fine. When I switched back > to the previous editor I found that the ^V's had taken effect there > instead!!! Do you really use 3.8 and not 4.2.x or 4.3?
This is a problem that occurred on 4.3M3 after I switched over from 3.8.1. In principle it should have nothing to do with 3.8.1 or 4.2.x except that the workspace is inherited from earlier Eclipse versions. [I've changed the version in the Bugzilla metadata; it seems to default to 3.8].
Bug 394517 and Bug 394536 may be different manifestations of a generic bad selection behaviour in 4.3M3.
Could be another problem caused by bug 375576.
A simple repro: While editing a Java file A, Edit so that a "Create method ... in type ... B " quick fix is offered. Select it. Active editor changes to the file for type B, but control functions such as control-C etc continue to the file for A.
(In reply to comment #5) > A simple repro: > > While editing a Java file A, > > Edit so that a "Create method ... in type ... B " quick fix is offered. > Select it. > > Active editor changes to the file for type B, but control functions such as > control-C etc continue to the file for A. I cannot reproduce this using our latest build: http://download.eclipse.org/eclipse/downloads/drops4/N20121125-2000/ Can you please check with that build and report back if you still see the problem and if so, provide more detailed steps.
(In reply to comment #6) > I cannot reproduce this using our latest build: > http://download.eclipse.org/eclipse/downloads/drops4/N20121125-2000/ > > Can you please check with that build and report back if you still see the > problem and if so, provide more detailed steps. The JUnit results do not look encouraging; is it safe to use generally, or do you just want me to look at this bug specifically?
(In reply to comment #7) > (In reply to comment #6) > > I cannot reproduce this using our latest build: > > http://download.eclipse.org/eclipse/downloads/drops4/N20121125-2000/ > > > > Can you please check with that build and report back if you still see the > > problem and if so, provide more detailed steps. > > The JUnit results do not look encouraging; is it safe to use generally, or > do you just want me to look at this bug specifically? I switch to the latest N-build from time to time since I work on the SDK. Of course I run into new bugs, but it's good to find them early. In your case it might be better to switch to the latest milestone build (M3) since the EPP packages are also available for them: http://www.eclipse.org/downloads/index-developer.php Regarding this concrete bug: I tried again and unfortunately the bug is still present in the latest build: 1. paste "public class A {}" into the 'Package Explorer' 2. paste the following into the 'Package Explorer': public class B { void test() { new A().bug(); } } 3. invoke 'Create method 'bug()' in type 'A' quick fix 4. press 'Esc' two times 5. copy the selection with Ctrl+C 6. paste the selection with Ctrl+V works as expected: paste happens in 'A' 7. close both editors (without saving) 8. open 'A', then 'B' 9. repeat 3 to 6 ==> works too 10. close both editors 11. open 'B', then 'A' and switch back to 'B' by clicking on the editor tab 12. repeat 3 to 6 ==> does not work, paste happens in wrong editor! It appears that it only works if 'A' is the first editor in the editor stack, e.g. if one first switches the tabs of 'A' and 'B' after step 11, then it also works, even if other editors are open.
(In reply to comment #8) > In your case it might be better to switch to the latest milestone build (M3) I'm alread using M3 for most things. Unfortunately GIT does not abide by normal Eclipse publishing policies. No downlopadable M3. > (In reply to comment #0) > > On M3 and almost certainly not reproducible. ... > Regarding this concrete bug: I tried again and unfortunately the bug is > still present in the latest build: So you now have a solid repro?
(In reply to comment #9) > (In reply to comment #8) > > In your case it might be better to switch to the latest milestone build (M3) > I'm alread using M3 for most things. Unfortunately GIT does not abide by > normal Eclipse publishing policies. No downlopadable M3. You can install it from here: http://eclipse.org/egit/download/ I usually use the nightly build which normally works well. > > (In reply to comment #0) > > > On M3 and almost certainly not reproducible. > ... > > Regarding this concrete bug: I tried again and unfortunately the bug is > > still present in the latest build: > > So you now have a solid repro? Yes. There's some variation though: - my previous comment / steps are based on N20121125-2000 - on M3 it's more broken in the sense that also having 'A' as first editor does not work for m3 - it works for me in 4.2, 4.2.1 and 4.3 M2 - it's also broken in the latest 4.2.2 build (M20121121-1200)
(In reply to comment #10) > (In reply to comment #9) > > (In reply to comment #8) > > > No downlopadable M3. > > You can install it from here: http://eclipse.org/egit/download/ > I usually use the nightly build Hardly a predictable download. > which normally works well. except that the one after M3 greyed out the commit capability (now ok)!
Eric, Bogdan, looks like clicking on the editor tabs can fail to switch focus in some scenarios. PW
(In reply to comment #12) > Eric, Bogdan, looks like clicking on the editor tabs can fail to switch > focus in some scenarios. After brief usage of M4, I don't seem to see the bad focus problem as originally reported. Now if I follow a "Create XXX.yyy" quick fix, the focus is over-eager on XXX.yyy, starting off with the "public" hover text that then needs killing.
I am still hitting this bug regularly. It seems to happen more frequently when Eclipse switches editor focus autonomously rather than by explicitly clicking on a tab. For example, if I try to use a non-existent method of an object, then accept Eclipse's suggestion to create that method, Eclipse switches over to the file containing the object's definition and positions me at the method stub -- but hitting control sequences such as Ctrl-P and Ctrl-N do not work until I manually switch tabs back and forth. I would ask that the maintainers please try to track this bug down. This bug is disruptive and destructive -- for example, if focus is partially lost and I hit Control-W, which is the emacs binding for deleting a region, it silently deletes a region from an editor I can't see. By the time I realize my control keystrokes are gone, the deleted region may be far back in the undo buffer (or even gone completely). Also, I did not start hitting this bug until I installed the patch for bug 394588. I reported this problem there originally, but was told to direct my comments to this bug instead.
With I20130101-0800 editors don't appear to get focus anymore when opening new files. If I double click a properties files in the Package Explorer the editor briefly gets focus and then the focus returns to the Package Explorer. When I open a Bugzilla task from the Task List the editor tab doesn't even get activated but a new tab is added to the editor area that is behind the active editor.
(In reply to comment #15) > With I20130101-0800 editors don't appear to get focus anymore when opening > new files. If I double click a properties files in the Package Explorer the > editor briefly gets focus and then the focus returns to the Package > Explorer. I tried with a "normal" Java properties file using the latest build: http://download.eclipse.org/eclipse/downloads/drops4/N20130109-2000/ and it works as expected. > When I open a Bugzilla task from the Task List the editor tab > doesn't even get activated but a new tab is added to the editor area that is > behind the active editor. Can't comment on this as I don't have Mylyn installed.
Works in M20121107-1200...but not in M20121121-1200... Paul, I've looked at the change logs from these dates, there's only about a dozen...could you take a look to see if you see anything that could be causing this ?
http://git.eclipse.org/c/platform/eclipse.platform.ui.git/commit/?h=R4_2_maintenance&id=6c9b9958d15b85e05dfc37ba2da273b988f20398 This fix forces a call to 'bringToTop' to instead call 'activate' if the part being brought forward is in the same stack as the currently active part (since it'll have to be activated in any case).
Steffen, I've closed this since it now supports the initially given repro scenario...I've you're continuing to experience the problems you describe either open a new defect and / or get in touch with me via email and I'll see what's up...for me I haven't experienced anything like this but I'm not using Mylyn...
This is going into RC3 so it should really have a review. Paul can you take a look at it?
I've reviewed it, and this should be available for RC2 PW
Verified in M20130116-1800.
This breaks the debug popups: they automatically close immediately.
To me it looks wrong to call activate(...) when the client only asked bringToTop(...).
Eric suggested to not activate when the part is the active part already and this does the trick: if (parent == activeParent) { activate(part); return; } ==> if (parent == activeParent && part != activePart) { ... }
(In reply to comment #25) > Eric suggested to not activate when the part is the active part already and > this does the trick: Or was it Paul?
If was me but what I was thinking was more along the lines of: if (parent == activeParent) { if (part != activePart) activate(part); return; } This just turns this case into a no-op altogether (i.e. no focus changing...) The problem is that the check you have negates the effect of the original fix because in that case the part *is* != activePart...
Dani, I'm obviously overloaded...I suspect our code is almost identical...let me try your suggestion against the given scenario
OK, your code and mine are effectively == so I'll go with the version you sent. My comment at the meeting was that since we return early from bringToTop *and* we don't activate there'll be no event fired for the BTT call...ok by me, you ?
(In reply to comment #29) > OK, your code and mine are effectively == so I'll go with the version you > sent. > > My comment at the meeting was that since we return early from bringToTop > *and* we don't activate there'll be no event fired for the BTT call...ok by > me, you ? yep + 1 for SR2 RC3 for the fix from comment 25.
http://git.eclipse.org/c/platform/eclipse.platform.ui.git/commit/?h=R4_2_maintenance&id=770558c4301ec0f5dc3f65d7a8b8616043030efb Augments the check as per Dani's code...
Verified in 4.2-M20130124-1700
Fixed copyright with http://git.eclipse.org/c/platform/eclipse.platform.ui.git/commit/?id=dd59f71d8db946b04892a0532a5e0468e86c922d Fixed in 'master' with http://git.eclipse.org/c/platform/eclipse.platform.ui.git/commit/?id=a2e2f8837e95480a5d2f8584724ccd5d0761238c
*** Bug 399971 has been marked as a duplicate of this bug. ***
M5a. The focus issue is clearly not resolved. I am now seeing what at the moment seem like unpredictable active editor changes, I think that it is usually, perhaps always, to the previously used editor.
(In reply to comment #35) > unpredictable active editor changes. Maybe not. I am stopped at a breakpoint in method A of file X. I modify the code of method B of file X. I save and so trigger an incremental compilation. The debugger refreshes and goes to line 1 of method A. Regression. In 3.x the editor context was unchanged in method B, it was necessary to click on the stack to change editor context to method A. Now in e4, my editor context can change while I type, certainly while I study. There seems to be a spurious 'activation' of the debugger context.
(In reply to comment #35) > M5a. The focus issue is clearly not resolved. > > I am now seeing what at the moment seem like unpredictable active editor > changes, I think that it is usually, perhaps always, to the previously used > editor. See also bug 403951.
(In reply to comment #36) > Now in e4, my editor context can change while I type, certainly while I > study. There seems to be a spurious 'activation' of the debugger context. It gets worse. Probably a dup of Bug 403560 or interacting with the latest Compare View 'improvements' (Bug 216407). Attempting to type in a (JDT) GIT compare view can change editor to the definition point.
(In reply to comment #38) > or interacting with the latest > Compare View 'improvements' (Bug 216407). Attempting to type in a (JDT) GIT > compare view can change editor to the definition point. This got fixed for today's I-build (see bug 403666).
*** Bug 396145 has been marked as a duplicate of this bug. ***
