Community
Participate
Working Groups
Quitting Eclipse with many editors opened, the caret starts disappearing after the next launch. Version: Luna M6 Release (4.4.0M6) Build id: 20140312-2027 Mac OS X 10.9.2 + Java 1.8.0-b132 Steps to reproduce: 1. Open several editors so that some of their tabs are 'hidden' in the 'Show List' icon. 2. Quit and relaunch Eclipse. 3. Switch to another editor by clicking the tab (or cmd+F6). 4. Switch to another editor again. (see additional info) Expected: The caret (cursor, pointer) is displayed in the switched editor. Actual: The caret is not displayed. It's still possible to type characters or move the (invisible) caret using the arrow keys. Additional info: - If you click the same tab twice, the caret appears. - If you close some editors so that all the tabs are displayed, the caret is displayed correctly when switching tabs. - Only when switching from the last opened editor, the caret seems to be displayed correctly. This is why the step 4 is required. - The problem did not reproduce in Luna M5 (I20140123-1600) on the same environment. - The problem did not reproduce on Windows 7 (64-bit) + JDK7.
Abhishek, can you please try this ? Thanks.
*** Bug 433275 has been marked as a duplicate of this bug. ***
I have found that the caret appears correctly if I commented out the call to forceLayout() method in org.eclipse.e4.ui.workbench.renderers.swt.WBWRenderer#postProcess() (line 742 in 9a64562). It's a part of the fix for bug 348954.
The invisible caret blocks normal work in the editor. The forceLayout() method mentioned in comment 3 should not have any effects on the caret visibility: private void forceLayout(Shell shell) { int i = 0; while(shell.isLayoutDeferred()) { shell.setLayoutDeferred(false); i++; } while(i > 0) { shell.setLayoutDeferred(true); i--; } }
(In reply to Markus Keller from comment #4) > The invisible caret blocks normal work in the editor. > > The forceLayout() method mentioned in comment 3 should not have any effects > on the caret visibility: > > private void forceLayout(Shell shell) { > int i = 0; > while(shell.isLayoutDeferred()) { > shell.setLayoutDeferred(false); > i++; > } > while(i > 0) { > shell.setLayoutDeferred(true); > i--; > } > } Caret.setFocus() is not getting called some times, causing this issue. Clicking on the tab the 2nd time does that. I'm still trying to understand the flow.
(In reply to Abhishek Kishore from comment #5) > > Caret.setFocus() is not getting called some times, causing this issue. > Clicking on the tab the 2nd time does that. I'm still trying to understand > the flow. Looks like this is happening because of changes made for bug 388574. Display.ignoreFocus is true during setFocus() on StyledText, which means FocusIn event on it is not being fired.
Created attachment 243308 [details] Revert bug 348954 on Mac If we don't find a very convincing explanation and solution in SWT, then we better just revert the hack for bug 348954 on the Mac. Starting up with a wrong focus is a minor issue compared to not seeing the caret.
(In reply to Markus Keller from comment #7) > Created attachment 243308 [details] > Revert bug 348954 on Mac > > If we don't find a very convincing explanation and solution in SWT, then we > better just revert the hack for bug 348954 on the Mac. Starting up with a > wrong focus is a minor issue compared to not seeing the caret. Confirmed that this change fixes the issue. Markus, I don't have committer rights on Platform-UI. We need a permanent solution for the issue, which'll be tracked via bug 433275.
(In reply to Markus Keller from comment #7) > Created attachment 243308 [details] [diff] > Revert bug 348954 on Mac > > If we don't find a very convincing explanation and solution in SWT, then we > better just revert the hack for bug 348954 on the Mac. Starting up with a > wrong focus is a minor issue compared to not seeing the caret. +1. I think this is the best we can do given we're in RC2.
Released as http://git.eclipse.org/c/platform/eclipse.platform.ui.git/commit/?id=90dca6c756f0e87da13797447c658d87db56c1ad Thanks Markus. PW
I opened Bug 435421 for the mac problem. PW
*** Bug 435458 has been marked as a duplicate of this bug. ***
Verified in 4.4.0.I20140522-1330.
(In reply to Paul Webster from comment #10) > Released as > http://git.eclipse.org/c/platform/eclipse.platform.ui.git/commit/ > ?id=90dca6c756f0e87da13797447c658d87db56c1ad Since the bug 433275 has been fixed (see comment 8), can we revert this commit?
(In reply to Wojciech Sudol from comment #14) > (In reply to Paul Webster from comment #10) > > Released as > > http://git.eclipse.org/c/platform/eclipse.platform.ui.git/commit/ > > ?id=90dca6c756f0e87da13797447c658d87db56c1ad > > Since the bug 433275 has been fixed (see comment 8), can we revert this > commit? Reverted with http://git.eclipse.org/c/platform/eclipse.platform.ui.git/commit/?id=57cbb8ced551819266aa83570f5fde75fe19a8ea.
(In reply to Wojciech Sudol from comment #15) > Reverted with > http://git.eclipse.org/c/platform/eclipse.platform.ui.git/commit/ > ?id=57cbb8ced551819266aa83570f5fde75fe19a8ea. Verified in 4.5 I20150126-2000 that after this revert the problem does not occur again.
