Community
Participate
Working Groups
Created attachment 268649 [details] Caret disappearing by clicking on different lines On Oxygen RC1 and RC2, the text editor caret (in JDT editors at least) is going missing very frequently, especially when I position it at the end of a line (by clicking or via the keyboard). Just clicking on the end of a line, then the line under it, and going back and forth fails almost instantly. Same for keyboard. I've attached a video (sorry this is an AVI, I tried to crop webm w/o success). I'm using Oxygen RC2 x86_64 with gtk3-3.22.15 (Fedora 26). I've checked for duplicates and there are many but for older versions, none for Oxygen yet. Hope it can be tackled before final release as it's extremely frustrating to work w/ the caret going missing every other second.
Works fine for me on RHEL 7.2 / gtk3-3.14.13-16.el7.x86_64
Looks like you're on Rawhide? - Is this a regression, I.e, did updating from F25 to F26 break things for you, or is this a first-time setup and things are not working? Was this working on F25? - Are you using the 'dark theme' eclipse? If so, does the issue occur in light theme (restart after switching themes). - Does it behave different with gtk2 backend? export SWT_GTK3=0 eclipse
- yes, F26 alpha - ho right, I forgot to add that there's no problem at all with Neon.3, this only regressed on Oxygen - i'm using the dark theme, but the bug is present both in the dark and light themes in Oxygen - no problem with gtk2 indeed I do not experience any kind of bug wrt to gtk 3.22 except this in Eclipse Oxygen. Would it somehow help to bisect to which release this regressed? M1, M2...? Could this partially narrow it down?
I can't seem to reproduce on my F25 setup. Might be something in W26 broke things. @Ian, this might be up your alley since you worked on related fixes maybe? I would suggest setting up a F26 vm.
I've bisected that regression to 4.7M6. In M5 everything is working fine. Hope this will help a bit.
(In reply to Missing name from comment #5) > I've bisected that regression to 4.7M6. In M5 everything is working fine. > > Hope this will help a bit. So as per https://wiki.eclipse.org/Eclipse/Release_checklist some where between January to March-ish. We'll probably have to setup a F26 vm to investigate this.
(In reply to Missing name from comment #5) > I've bisected that regression to 4.7M6. In M5 everything is working fine. > > Hope this will help a bit. Hey, It might have to do with something I did related to cursor drawing here: https://bugs.eclipse.org/bugs/show_bug.cgi?id=517487
(In reply to Ian Pun from comment #7) > https://bugs.eclipse.org/bugs/show_bug.cgi?id=517487 This link points to this bug. Copy & paste typo?
Is this with wayland or x11? I'm on f26 alpha gnome on wayland and don't see the issue.
ah, sorry, this is the real bug: https://bugs.eclipse.org/bugs/show_bug.cgi?id=500013
I have the problem on both x11 and wayland backends. I also just tried the recently-released RC3, same issue. The bug linked might indeed be the source of the issue. Can you tell me if I can retest in an upcoming integration milestone or the last RC maybe?
(In reply to Missing name from comment #11) > I have the problem on both x11 and wayland backends. > > I also just tried the recently-released RC3, same issue. > > The bug linked might indeed be the source of the issue. Can you tell me if I > can retest in an upcoming integration milestone or the last RC maybe? Could you try with latest integration here: http://download.eclipse.org/eclipse/downloads/ See "4.7 Integration Builds" section, click on something like: I20170608-0530 , then find your platform like Linux x86_64 under Eclipse sdk.
It's the same with this build. I'm running latest Fedora 26 (which is stated for release as beta next tuesday, final release is targeted the 11th of july ATM). Still works with Neon.3.
ha I see why nobody got the issue earlier. I always disabled the cursor blink on my desktop through the org.gnome.desktop.interface cursor-blink gsettings key. If I enable it back, the blinking helps to find out the cursor. But even in this configuration, it does not seem to work like it used to be. At the very moment the cursor is moved through mouse or keyboard, whether the caret is visible or not, it used to be made visible again (it's the same on Windows, MacOSX, Gtk ...) so it's easy to find it, like restarting a timeout until it's hidden. But it does not behave like that, the blinking keeps getting on / off at the same interval whether we move or not the cursor. Maybe the origin is be the same.
(In reply to Missing name from comment #14) > ha I see why nobody got the issue earlier. I always disabled the cursor > blink on my desktop through the org.gnome.desktop.interface cursor-blink > gsettings key. > > If I enable it back, the blinking helps to find out the cursor. But even in > this configuration, it does not seem to work like it used to be. > > At the very moment the cursor is moved through mouse or keyboard, whether > the caret is visible or not, it used to be made visible again (it's the same > on Windows, MacOSX, Gtk ...) so it's easy to find it, like restarting a > timeout until it's hidden. > > But it does not behave like that, the blinking keeps getting on / off at the > same interval whether we move or not the cursor. Maybe the origin is be the > same. The current method with how the caret is being drawn has changed a bit over time, but ultimately should not be a usability problem anymore. If the general problem of the caret being actually "missing" is not there anymore, I would suggest we close this bug.
Well, I'm not sure I'm easy to follow, but this is still broken on Fedora 26 Beta (almost final freeze), whether I activate cursor blinking or not. If do not, I almost never see the caret, if I do, it's made visible at each keypress, which is barely usable.
Not sure why this is assigned to swt-traged@eclipse.org, re-assigning to the regular inbox.
I'm getting this problem too, I'm on a fresh Gentoo x86-64 4.9.34, with X11, i3wm, and Gtk 3.22.15, running Oxygen release 4.7.0 I don't get the disappearing act on the ends of lines but the caret blink is definitely different. It continues to blink as if the user were idle even when I'm typing. I use vrapper so it's very noticeable and destroys my ability to quickly navigate with the keyboard.
I'm getting this problem on Fedora25 with all the latest updates installed running Oxygen release 4.7.0 x86_64. If you use down arrow key to move down the page, the caret only appears on every 2nd line. If you click with the mouse at the beginning of a line it may take one or more clicks for the caret to appear. Likewise when clicking the middle of a line. If you click in the space past the end of the line the caret will not appear on every 2nd line.
(In reply to Steven Nuzum from comment #19) > I'm getting this problem on Fedora25 with all the latest updates installed > running > Oxygen release 4.7.0 x86_64. > > If you use down arrow key to move down the page, the caret only appears on > every 2nd line. > Hi Steven, this is likely due to how the blinking mechanism is done for carets. The assumption is that the caret blinks every half a second, but if you move the caret inbetween an interval, it screws up the blinking flags, causing it possibly to not show at all. I will be working on fixing this.
New Gerrit change created: https://git.eclipse.org/r/100860
Just an update, the reason for some of the blinking issues of it disappearing is likely due to the fact that the scrollbar is sending out a spam of draw signals that causes the caret to blink very very fast, causing stuttering/pausing. In regards to the blinking mechanism, this issue began starting with GTK3. However, A few of the caret changes I did in Bug 500013 may have affected it more intensely on X11 as well. The current Gerrit change will move the blinking mechanism back to prior my Wayland fix if you are on X11. I still do notice that the caret disappears once in a while, but please do let me know if has improved.
I see this issue under Fedora 25, X11, gtk-3 3.22.16 & Eclipse Oxygen 4.7.0. The caret disappears on odd columns (if the first is column 0). As I move the cursor along the line it appears and disappears. (The cursor is not set to blink)
It's definitely related to the scrollbar. As I scroll, the caret appears and disappears.
New Gerrit change created: https://git.eclipse.org/r/101926
Gerrit change https://git.eclipse.org/r/101926 was merged to [master]. Commit: http://git.eclipse.org/c/platform/eclipse.platform.swt.git/commit/?id=44c4faf4c081e6824275571292883da6d93d4ed1
(In reply to Eclipse Genie from comment #26) > Gerrit change https://git.eclipse.org/r/101926 was merged to [master]. > Commit: > http://git.eclipse.org/c/platform/eclipse.platform.swt.git/commit/ > ?id=44c4faf4c081e6824275571292883da6d93d4ed1 In master now, thanks for the patch Ian! This makes cursors a lot more smooth.
Created attachment 269545 [details] caret performance fix Screencasting doesn't take all the frames, please try for yourself :)
Left is the fixed version, right is the pre-patch (regarding webm).
I suggest to downport this to 4.7.1 once this feature got a bit more testing in the usage of the 4.8 stream
OK, so how exactly do I fix this caret blinking/disappearing issue? Do we have a build that incorporates the fix? I'm running 4.7.0 and it's almost impossible to type code in the editor.
(In reply to Calin Crisan from comment #31) > OK, so how exactly do I fix this caret blinking/disappearing issue? Do we > have a build that incorporates the fix? I'm running 4.7.0 and it's almost > impossible to type code in the editor. That version does not have the fix in it. To get the version with it fixed: 1) Download yesterday's I-build: http://download.eclipse.org/eclipse/downloads/drops4/I20170802-2000/ or 2) Download 4.8 M1: http://download.eclipse.org/eclipse/downloads/drops4/S-4.8M1-201708022000/ Either one of those options will have the fix included.
Hi Eric, We are in 4.7.1 RC3 week already, do you still want to push this for 4.7.1? If yes, you need to ask for PMC approval. If not, please move the target to 4.7.2.
(In reply to Lakshmi Shanmugam from comment #33) > Hi Eric, > We are in 4.7.1 RC3 week already, do you still want to push this for 4.7.1? > If yes, you need to ask for PMC approval. If not, please move the target to > 4.7.2. Sorry, lost track of this bug. Will send an email out.
New Gerrit change created: https://git.eclipse.org/r/103771
Gerrit change https://git.eclipse.org/r/103771 was merged to [R4_7_maintenance]. Commit: http://git.eclipse.org/c/platform/eclipse.platform.swt.git/commit/?id=0000f83f1701abe0a7de15c642bb62b517318bd0
(In reply to Eclipse Genie from comment #36) > Gerrit change https://git.eclipse.org/r/103771 was merged to > [R4_7_maintenance]. > Commit: > http://git.eclipse.org/c/platform/eclipse.platform.swt.git/commit/ > ?id=0000f83f1701abe0a7de15c642bb62b517318bd0 Backport merged.
(In reply to Eric Williams from comment #37) > (In reply to Eclipse Genie from comment #36) > > Gerrit change https://git.eclipse.org/r/103771 was merged to > > [R4_7_maintenance]. > > Commit: > > http://git.eclipse.org/c/platform/eclipse.platform.swt.git/commit/ > > ?id=0000f83f1701abe0a7de15c642bb62b517318bd0 > > Backport merged. Thanks for the backport Eric!
Hi Eric/Ian, Can you please verify the fix on the 4.7.1RC3 candidate build - http://download.eclipse.org/eclipse/downloads/drops4/M20170830-1700/ ?
(In reply to Lakshmi Shanmugam from comment #39) > Hi Eric/Ian, > Can you please verify the fix on the 4.7.1RC3 candidate build - > http://download.eclipse.org/eclipse/downloads/drops4/M20170830-1700/ ? Hi Lakshmi, I can confirm that this fix is in 4.7.1RC3, tested on both Wayland and X11.
*** Bug 520471 has been marked as a duplicate of this bug. ***
New Gerrit change created: https://git.eclipse.org/r/104582
Gerrit change https://git.eclipse.org/r/104582 was merged to [master]. Commit: http://git.eclipse.org/c/www.eclipse.org/eclipse/news.git/commit/?id=24670cd7b66d0eb3147462801405837fff601036
*** Bug 413837 has been marked as a duplicate of this bug. ***
