Community
Participate
Working Groups
I've noticed in the 4.20 release that when I klick at the end of a method name in the method signature (just before the opening bracket) and start inserting characters then the newly inserted text is not visible for a while and some UI glitching happens. This was not the case in 4.19.
Created attachment 286642 [details] Screen recording showing the editor cheese I see that too. See screen recording in the attachment.
> I see that too. See screen recording in the attachment. To clarify: I'm typing "StandardFileManager" at the caret location. No characters appear; right parentheses get duplicated at the end of the line, and there is some pixel cheese where the characters should appear (as if they were xored or maybe written in white over the existing text, which should have been moved to the right). Once I stop typing the display fixes itself. I've seen similar cheese also in some cases involving string literals, but cannot find a reproducible case right now. OS X 10.14.6, Eclipse 2021-06.
Moving to JDT for analysis.
This is happening in CDT editor as well. Start typing then there's drawing errors ("random" pixels) and a delay before seeing the typed results. I updated from 2021-03 to: Eclipse: Version: 2021-06 (4.20.0) Build id: 20210612-2011 CDT: Version: 9.11.1.202006011430 Build id: 20200601-1605 macOS: 10.15.7 (19H1217)
(In reply to Greg Willits from comment #4) > This is happening in CDT editor as well. > > Start typing then there's drawing errors ("random" pixels) and a delay > before seeing the typed results. > > I updated from 2021-03 to: However I am not seeing it in a second instance I have (same computer) which I installed 2021-06 fresh. So, possibly related to updated instances only?
Created attachment 286650 [details] Typing Update Delay 2021-06 Shows the delays in updating text in the editor (CDT in this case). You'll see random pixel changes, but not until I stop typing does the line update.
Now that I've been using this more today, another way to describe it is that as long as I keep typing, the view does not update correctly until after I stop typing and wait 1-2 seconds. The view is being updated - I see random pixels changing, but it's not legible. Thomas's video won't play for me, so I am attaching one as well just in case that helps. If that doesn't work, I'll try some frame grabs from it. Also, I created a new .txt file, and the problem does not show up in that file. So it may be limited to files with interactive parsers?
Created attachment 286651 [details] Frames from attached GW video Frames from my video -- (A) Before typing (B) During typing there are random pixel changes, but not until I stop typing (C) does the line update correctly.
I've just noticed that the editor shows the new text with almost no delay if I share my eclipse window in MS Teams but stops working as soon as I stop sharing. I just wanted to share this information in case it helps.
(In reply to Greg Willits from comment #5) > (In reply to Greg Willits from comment #4) > > This is happening in CDT editor as well. > > > > Start typing then there's drawing errors ("random" pixels) and a delay > > before seeing the typed results. > > > > I updated from 2021-03 to: > > However I am not seeing it in a second instance I have (same computer) which > I installed 2021-06 fresh. > > So, possibly related to updated instances only? I tried switching my projects over to the new installed instance of -06 (for which I created it's own workspace) by just pointing it to my production workspace (well, a copy of it). The typing bugs resurfaced. Also, it's not that just a delay in seeing the typing, I usually have to press Return in order to get the view to refresh so I can see what I just typed -- even if I just edit a word on a line, it's all garbage until I force a refresh with a Return (and then delete it. It's pretty intolerable, and really slowing me down -- definitely not a P3 bug IMO. Do we know if anyone is looking into this yet. I'll try some other experiments to try to tease out some clues. At this point I'm going to have to try rebuilding my entire environment and preferences up from scratch and see what happens.
Here's a very simple reproducer: With the following Java class: import java.util.List; public class Foo { public List<String> foo(List<String> arg) { return arg; } } Select "List" (either one) in the "foo" method declaration. Type "Collection". Observe characters typed not being shown and '>' getting duplicated (and drawn with a box around) until you stop typing. Reproduced in a epp.java package, OS X 10.14.6, Version: 2021-06 (4.20.0) Build id: 20210612-2011
Bumping importance to "critical". This is super-annoying in daily work.
I do wonder if https://git.eclipse.org/r/c/platform/eclipse.platform.text/+/177140/2/org.eclipse.jface.text/src/org/eclipse/jface/text/contentassist/CompletionProposalPopup.java#b962 has something to do with this.
(In reply to Thomas Wolf from comment #13) > I do wonder if > https://git.eclipse.org/r/c/platform/eclipse.platform.text/+/177140/2/org. > eclipse.jface.text/src/org/eclipse/jface/text/contentassist/ > CompletionProposalPopup.java#b962 has something to do with this. Moving to Platform/Text for further analysis. As per comment 5 updated the bug title as well, since the problem is specific to Eclipse updated to 2021-06 and not fresh Eclipse.
(In reply to Niraj Modi from comment #14) > (In reply to Thomas Wolf from comment #13) > > I do wonder if > > https://git.eclipse.org/r/c/platform/eclipse.platform.text/+/177140/2/org. > > eclipse.jface.text/src/org/eclipse/jface/text/contentassist/ > > CompletionProposalPopup.java#b962 has something to do with this. > > Moving to Platform/Text for further analysis. > > As per comment 5 updated the bug title as well, since the problem is > specific to Eclipse updated to 2021-06 and not fresh Eclipse. That's wrong; also occurs on EPP downloads. See comment 11.
Just a quick thought: Could this be specific to macOS versions prior to Big Sur (11.x)? Seems to me like the environments where this got reproduced so far are running macOS 10.14 or 10.15, whereas my environment (where I couldn't reproduce this) was running macOS 11.4.
(In reply to Martin Lippert from comment #16) > Just a quick thought: Could this be specific to macOS versions prior to Big > Sur (11.x)? Seems to me like the environments where this got reproduced so > far are running macOS 10.14 or 10.15, whereas my environment (where I > couldn't reproduce this) was running macOS 11.4. That's quite possible; it's why I always mentioned I saw it on 10.14.6. :-)
I'm on macos 10.14.6 and this is happening to me as well on 4.20. I was holding off on upgrading as I have an older mac but I guess I should just do it now.
I'm running macOS 10.15.7 but my organisation doesn't allow an update so I'm stuck with this bug until it's fixed. Is there any information if the reason is known and a possible fix is in work?
This bug seems related to bug 574869 (thanks Thomas Wolf), then it might be due to Java version. That bug manifests with Java 14 or later (but not with Java 11), but Eclipse 2021-06 came packaged with Java 16. Questions (for people running Mac Catalina): (1) If you run Eclipse 2021-06 with Java 11, does the problem go away? (2) If you run Eclipse 2019-09 with Java 14, does the problem appear? I just tested this myself, and found running 2019-09 with Java 14 shows the same problem in comment 11, and conversely running Eclipse 2021-06 under Java 11 does *not* show the problem. If this is confirmed by others, it means we don't need to waste time looking at code changes in Eclipse 2021-06, but rather 2019-09 (and Java 14 versus Java 11).
These are the Jars for Java 11, 14 and 16 I tested Eclipse with: org.eclipse.justj.openjdk.hotspot.jre.full.macosx.x86_64_11.0.2.v20200815-0835 org.eclipse.justj.openjdk.hotspot.jre.full.macosx.x86_64_14.0.2.v20200815-0932 org.eclipse.justj.openjdk.hotspot.jre.full.macosx.x86_64_16.0.1.v20210528-1205 To repeat: I am able to replicate the behavior of comment 11 with the second and third of these, but not with the first. (In Eclipse 2019-09 and later). And just for completeness, I have verified that 2019-06 does *not* have the behavior *even* when running under Java 14.
BTW: The way I ran Eclipse under different versions was by running it under itself with a different JRE set. Just changing eclipse.ini to use the jli.dylib from Java 11 is not enough to fix running 2021-06 from the top. I expect it's not Java 14 per se, but the SWT library for Java 14, or something like that.
(In reply to John Boyland from comment #20) > I just tested this [comment 11] myself, and found running 2019-09 with Java 14 shows the > same problem in comment 11, and conversely running Eclipse 2021-06 under > Java 11 does *not* show the problem. I'm seeing the typing problems (which I've now seen manifest in multiple ways), and setup is as follows: macOS 10.15.7 Eclipse CDT: Version: 2021-06 (4.20.0) Build id: 20210612-2011 My Java version from CLI: % java --version java 11.0.8 2020-07-14 LTS Java(TM) SE Runtime Environment 18.9 (build 11.0.8+10-LTS) Java HotSpot(TM) 64-Bit Server VM 18.9 (build 11.0.8+10-LTS, mixed mode) My Eclipse Configuration: -vm /Library/Java/JavaVirtualMachines/jdk-11.0.8.jdk/Contents/Home/bin/../lib/server/libjvm.dylib eclipse.vm=/Library/Java/JavaVirtualMachines/jdk-11.0.8.jdk/Contents/Home/bin/../lib/server/libjvm.dylib
With regard to comment 23: just changing the -vm is not enough to use Java 11 throughout. But try this: start up 2021-06 and then go to Preferences and create a Installed JRE for Java 11 pointing to the jre in the Java home for Java 11. Then run an Eclipse application using this JRE, not the default one (need to go to Run Configurations and change the Runtime JRE to point to the Java 11 JRE that you created). Then in the sub-eclipse, create a Java project and try to replicate comment 11. So it's not Java 14/16 per se that's the problem but maybe one of the libraries that comes with it, it seems? Not sure; I don't know why using -vm is different than using a JRE in an Eclipse application. If you use the default Java Runtime Environment, the bug will be replicated in the sub-eclipse. You have to use a Java 11 JRE to avoid the problem.
(In reply to John Boyland from comment #24) > With regard to comment 23: just changing the -vm is not enough to use Java > 11 throughout. But try this: start up 2021-06 and then go to Preferences > and create a Installed JRE for Java 11 pointing to the jre in the Java home > for Java 11. Then run an Eclipse application using this JRE There's nothing in my Preferences (according to filtering) which alludes to anything about reconfiguring JREs. If you're talking about something like this process: https://www.baeldung.com/eclipse-change-java-version ...yeah, I don't have that (AFAICT). I'm using CDT, and not writing any Java of any kind. If what I'm talking about is irrelevant to what you're trying to have me do, well, then yeah, I'm confused :-)
In reply to Comment 25, I was (incorrectly for you) assuming people here had a "Eclipse for Eclipse Committers" executable. Sorry! No wonder what I wrote made no sense.
Occurs in a freshly downloaded Eclipse SDK I20210721-1800 from [1], irrespective of the JVM used. (I tried adoptopenjdk 11 and 16.) Did not occur in 2021-03. [1] https://download.eclipse.org/eclipse/downloads/drops4/I20210721-1800/download.php?dropFile=eclipse-SDK-I20210721-1800-macosx-cocoa-x86_64.dmg
(In reply to Thomas Wolf from comment #13) > I do wonder if > https://git.eclipse.org/r/c/platform/eclipse.platform.text/+/177140/2/org. > eclipse.jface.text/src/org/eclipse/jface/text/contentassist/ > CompletionProposalPopup.java#b962 has something to do with this. Could you revert this commit and test if this fixes the problem?
(In reply to Lars Vogel from comment #28) > (In reply to Thomas Wolf from comment #13) > > I do wonder if > > https://git.eclipse.org/r/c/platform/eclipse.platform.text/+/177140/2/org. > > eclipse.jface.text/src/org/eclipse/jface/text/contentassist/ > > CompletionProposalPopup.java#b962 has something to do with this. > > Could you revert this commit and test if this fixes the problem? Done. Wasn't that commit. (Issue is reproducible in a child Eclipse running on a JVM > 11, for instance on adoptopenjdk16.)
This looks like Bug 569147 which was earlier fixed for BigSur. I believe the behaviour is now seen on the older macOS versions as well because the Eclipse launcher was rebuilt with 10.14 SDK for 4.20 (Bug 572187), causing the problem in Eclipse 4.20. Applying the change from Bug 569147 to all Mac OS versions (i.e, removing the version check) should fix the problem in Eclipse. Niraj, can you please help creating the patch?
Release below bug fix w.r.t. to SWT master, will be available in next IBuild: https://git.eclipse.org/r/c/platform/eclipse.platform.swt/+/183588 https://git.eclipse.org/c/platform/eclipse.platform.swt.git/commit/?id=bf98613e5249d80c7f026a9d1234345a1ba342be
Thanks Lakshmi for your input & Thomas for the testing the gerrit patch, resolving now.
*** Bug 574585 has been marked as a duplicate of this bug. ***
*** Bug 574896 has been marked as a duplicate of this bug. ***
*** Bug 574648 has been marked as a duplicate of this bug. ***
