Community
Participate
Working Groups
When switching editor tabs the editor is not automatically focused in the latest (yesterday evening) I build. A related test is failing on Gerrit too (not on the nightly build though): https://ci.eclipse.org/platform/job/eclipse.platform.ui-Gerrit/20754/testReport/junit/org.eclipse.e4.ui.tests.workbench/PartOnTopManagerTest/test_PartOnTopPerspectiveSwitch/ Eclipse SDK Version: 2019-12 (4.14) Build id: I20191110-1800 OS: Linux, v.5.3.0-19-generic, x86_64 / gtk 3.24.12, WebKit 2.26.1 Java version: 1.8.0_222
Works for me, RHEL 7.4, same SDK build. Concrete steps to reproduce?
Maybe related, we see the following test fail on Gerrit: org.eclipse.e4.ui.tests.workbench.PartOnTopManagerTest.test_PlaceholderOnTopStackSwitch
(In reply to Lars Vogel from comment #2) > Maybe related, we see the following test fail on Gerrit: > > org.eclipse.e4.ui.tests.workbench.PartOnTopManagerTest. > test_PlaceholderOnTopStackSwitch For example: https://git.eclipse.org/r/#/c/152414/
(In reply to Andrey Loskutov from comment #1) > Works for me, RHEL 7.4, same SDK build. > > Concrete steps to reproduce? For me, I just opened a bunch of editors (Java for that matter) and then switched between them. Once I clicked on a tab and the respective editor opened I expect to be inside the editor and that I can type inside the editor which is not the case. OS is Ubuntu 19.10
(In reply to Jonas Hungershausen from comment #4) > (In reply to Andrey Loskutov from comment #1) > > Works for me, RHEL 7.4, same SDK build. > > > > Concrete steps to reproduce? > > For me, I just opened a bunch of editors (Java for that matter) and then > switched between them. Once I clicked on a tab and the respective editor > opened I expect to be inside the editor and that I can type inside the > editor which is not the case. So you are not inside the editor or you can't type? Could it be just painting issue - obviously, you *can* type via keyboard, but I guess you can't see changed text and/or editor tab is not getting dirty "*" sign? *I* can type after switching editors by clicking on the editor tab or by using "next editor" shortcut. How do *you* switch editors? Any errors in the log? If you can reproduce, please either provide a video or write down exact steps (opened editor via double click in packages view, etc).
Created attachment 280592 [details] GIf showing the steps So the problem doesn't occur when I directly switch between tabs (as I incorrectly described earlier—sorry!). It rather happens, when I switch from an editor to another part, then switch to a different editor tab and then back to the original one. As you can see in the video, once I was back to the "FlutterLibChangeListener" at the end I couldn't type, which I don't think is intended.
OK, now with a *different* set of files and my own steps I see the problem. 1) In Java perspective, close all editors 2) Double click on /org.eclipse.swt/Eclipse SWT/common/org/eclipse/swt/SWT.java to open SWT.java. Note that the cursor is there, typing is possible. 3) Double click on /org.eclipse.swt/Eclipse SWT/common/org/eclipse/swt/SWTError.java to open SWTError.java. Note that the cursor is there, typing is possible. 4) Click once on the SWT.java editor tab to switch back to SWT.java. Note that the cursor is NOT there, typing does not have any visible effect. Only clicking with the mouse *inside* the editor text area allows you to change the text. From the recent changes I could imagine bug 371545 is the cause, but I haven't verified that yet. Eric, could you check?
Interestingly, I can't reproduce this behavior in the debugger, it just works. Why that? Some SDK project in my workspace that prevents it to happen?
*sigh* it's always something. I'll investigate. Unrelated: I did not get emailed for this incoming bug report, even though I follow platform-swt-inbox and it's been working for years...
I can't reproduce the steps from comment 6 or comment 7. This is using a child Eclipse on SWT master, Fedora 31, GTK3.24. Let me try a standalone build.
(In reply to Eric Williams from comment #10) > I can't reproduce the steps from comment 6 or comment 7. This is using a > child Eclipse on SWT master, Fedora 31, GTK3.24. > > Let me try a standalone build. Yep, see comment 8.
Okay, was able to reproduce the issue in a child Eclipse using steps from comment 6. Oddly enough it only reproduces if you click in the Outline part after editing the first file. Clicking anywhere else doesn't reproduce it. The issue reproduces with bug 371545 reverted, so I don't think it's that.
I must confess that I haven't tried with Windows. May be it is not SWT, but platform UI?
(In reply to Andrey Loskutov from comment #13) > I must confess that I haven't tried with Windows. May be it is not SWT, but > platform UI? Could be. My steps to reproduce: 1) Have two files open in the Java perspective. 2) Click the tab of the first file. Type some stuff, hit Ctrl+z so nothing is edited. 3) Click into the blank area of the "Outline" view. 4) Click the tab of the second file. Type some stuff, hit Ctrl+z so nothing is edited. 5) Click tab of first file. Notice that the cursor isn't painted and nothing will be typed if you press a bunch of keys.
(In reply to Andrey Loskutov from comment #7) > OK, now with a *different* set of files and my own steps I see the problem. > > 1) In Java perspective, close all editors > 2) Double click on /org.eclipse.swt/Eclipse > SWT/common/org/eclipse/swt/SWT.java to open SWT.java. Note that the cursor > is there, typing is possible. > 3) Double click on /org.eclipse.swt/Eclipse > SWT/common/org/eclipse/swt/SWTError.java to open SWTError.java. Note that > the cursor is there, typing is possible. > 4) Click once on the SWT.java editor tab to switch back to SWT.java. Note > that the cursor is NOT there, typing does not have any visible effect. Only > clicking with the mouse *inside* the editor text area allows you to change > the text. > > From the recent changes I could imagine bug 371545 is the cause, but I > haven't verified that yet. > > Eric, could you check? Could reproduce those steps on Windows 7. Same result.
Same for Eric's steps in comment 14.
(In reply to Eric Williams from comment #12) > The issue reproduces with bug 371545 reverted, so I don't think it's that. Sorry Eric, was just a first guess. (In reply to Paul Pazderski from comment #16) > Same for Eric's steps in comment 14. Thanks Paul. Had no time to test on Windows.
A more dense version of Eric's steps. The Ctrl+Z isn't necessary. 1. In an open editor, click on outline view (not necessary the empty part). 2. Select another editor. 3. Switch back to the first editor. Now most typing seem to be lost but in fact it is entered in the previous editor. At the same time key commands like Ctrl+Z or Alt+Up are not sent to the previous editor but processed by the selected editor.
Regression is in (I20190920-1800, I20190923-0615] range, I have no versions in between, but reverting commit aa8cc8120a501ef61938bd9f39c63ff26c71b1d6 fixes the problem in comment 18, so bug 473941 is it. Can't reproduce my steps from comment 7 on Windows. I will revert that change now.
(In reply to Andrey Loskutov from comment #19) > I will revert that change now. https://git.eclipse.org/r/152448
(In reply to Andrey Loskutov from comment #19) > I will revert that change now. Gerrit change https://git.eclipse.org/r/152448 was merged to [master]. Commit: http://git.eclipse.org/c/platform/eclipse.platform.ui.git/commit/?id=b00c85436f067e43337eedae4095db9e5fd407eb Reverted commit is in build I20191111-1800, here I can't reproduce neither comment 7 nor comment 18 steps anymore (on Linux), so that was it, marking this bug as resolved. Thanks Jonas for catching this issue!
