Bug 574869 - DefaultCharacterPairMatcher leaves visual traces in Java 14 or later
Summary: DefaultCharacterPairMatcher leaves visual traces in Java 14 or later
Status: NEW
Alias: None
Product: Platform
Classification: Eclipse Project
Component: Text (show other bugs)
Version: 4.21   Edit
Hardware: PC Mac OS X
: P3 normal (vote)
Target Milestone: ---   Edit
Assignee: Platform-Text-Inbox CLA
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2021-07-15 13:41 EDT by John Boyland CLA
Modified: 2021-07-16 12:12 EDT (History)
2 users (show)

See Also:


Attachments
Screen recording showing bug in action (15 sec) (688.07 KB, video/quicktime)
2021-07-15 13:41 EDT, John Boyland CLA
no flags Details
screenshot of editor in action (129.65 KB, image/png)
2021-07-15 13:42 EDT, John Boyland CLA
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description John Boyland CLA 2021-07-15 13:41:02 EDT
Created attachment 286792 [details]
Screen recording showing bug in action (15 sec)

I'm using DefaultCharacterPairMatcher in a simple language plugin.  When running in Eclipse 2019-09 or later and using Java 14 or later (no problem with Java 11 -- I don't have Java 12 or 13), when one types a closing character from the pair, the screen doesn't show it, and even the following character is invisible.  Only after a third character is pressed are all characters shown.

I have replicated the problem with the built-in "XML Editor" plugin created by Wizard with the following three changes:
(1) Change extension to "xxml" in plugin.xml because otherwise Eclipse's preloaded XML editor takes charge.
(2) Add the following the XMLEditor:
```
	@Override
	protected void configureSourceViewerDecorationSupport (SourceViewerDecorationSupport support) {
		super.configureSourceViewerDecorationSupport(support);		

		
		IPreferenceStore store = getPreferenceStore();
		store.setDefault(PreferenceConstants.EDITOR_MATCHING_BRACKETS, true);
		store.setDefault(PreferenceConstants.EDITOR_MATCHING_BRACKETS_COLOR, "127,0,85");
		
		char[] matchChars = {'(', ')', '[', ']'};	
		ICharacterPairMatcher matcher = new DefaultCharacterPairMatcher(matchChars ,
				IDocumentExtension3.DEFAULT_PARTITIONING);
		support.setCharacterPairMatcher(matcher);
		support.setMatchingCharacterPainterPreferenceKeys(
				PreferenceConstants.EDITOR_MATCHING_BRACKETS,
				PreferenceConstants.EDITOR_MATCHING_BRACKETS_COLOR);
		
        }
```
(3) Create PreferenceConstants.java with:
```
public class PreferenceConstants {

	public static final String EDITOR_MATCHING_BRACKETS = "matchtest.matching.brackets";
	public static final String EDITOR_MATCHING_BRACKETS_COLOR = "matchtest.matching.brackets.color";	

}
```
Then start an Eclipse application and create a project and a file "test.xxml" in which you type `(x)y=3` slowly and see what happens after each key press:
- after "(", it appears as expected
- after "x", it appears as expected
- after ")", nothing appears, but if ")" was pressed while the cursor was blinked on, then the old cursor will still be visible even as the new cursor is blinking.
- after "y", nothing appears, but again, if the "y" was pressed while the cursor was blinked on, then that cursor will still be visible, even as the new cursor is blinking.
- after "3", all characters appear where they are expected to be.

The attached small/short movie shows the bug in action.  I'll try to post a screenshot of a still (just before pressing "3") in an update.

This happens under MacOS Catalina.
Comment 1 John Boyland CLA 2021-07-15 13:42:27 EDT
Created attachment 286793 [details]
screenshot of editor in action

This show the editor just before "3" is pressed.
Comment 2 Thomas Wolf CLA 2021-07-15 15:11:20 EDT
I suppose this is a duplicate of bug 574351.
Comment 3 John Boyland CLA 2021-07-15 15:30:23 EDT
The bug does look similar except:

- The visual problem is long-lasting.  If one stops typing after the first character, then for at least 10 seconds the glitch stays in effect, but yes, if one changes to another application, the glitch vanishes.  That made it very hard to get a screenshot: it would fix itself when a timed screenshot reached 0 sec.  The screenshot I showed is a still from the screen movie recording.

- People say it is only in 2021-06.  FOr my bug, I found it happens in 2019-09 too, but only if one runs in Java 14 or later.  2021-06 was the first to be packaged by default on the mac with a Java 16.  Earlier distros used local Java which was often 8 or 11.

If it's the same bug, then the Java version is an important clue.  As is the fact that the bug first appeared in 2019-09.