JDK-4666876 : REGRESSION: TextArea shows only first letter of each word after appending "\r\n"
  • Type: Bug
  • Component: client-libs
  • Sub-Component: java.awt
  • Affected Version: 1.4.0
  • Priority: P4
  • Status: Resolved
  • Resolution: Fixed
  • OS: windows_98
  • CPU: x86
  • Submitted: 2002-04-11
  • Updated: 2002-09-06
  • Resolved: 2002-09-06
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
Other
1.4.2 mantisFixed
Related Reports
Relates :  
Description

Name: jk109818			Date: 04/11/2002


FULL PRODUCT VERSION :
java version "1.4.0"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.0-b92)
Java HotSpot(TM) Client VM (build 1.4.0-b92, mixed mode)


FULL OPERATING SYSTEM VERSION :
Windows 98 [Version 4.10.2222]

A DESCRIPTION OF THE PROBLEM :
When the method java.awt.TextArea.append(...) is used to
append "\r\n" to a TextArea that is currently showing on
the screen, only the first letter of each word that comes
after the "\r\n" will be displayed on the screen, until the
next repaint of the TextArea. All letters after the first
letter seem to take the background color and will not show
before the TextArea is manually resized or a redraw is
forced in some other way.
The bug appears with JDK 1.4.0 under Windows 98.
The TextArea class works fine with JDK 1.3.1_01 under
Windows 98 and also with JDK 1.1.7B and JDK 1.3.0 under
Linux x86.




REGRESSION.  Last worked in version 1.3.1

STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
1. Run the supplied class "TextAreaBug"


EXPECTED VERSUS ACTUAL BEHAVIOR :
The expected display in the TextArea is, of course:

This line will be fine.
This line will be messed up.

However, with JDK 1.4.0-b92 under Windows98 4.10.2222 you
will see:

This line will be fine.
T    l    w    b  m      u

The missing characters will appear when areas of the window
are hidden by other windows and then exposed again, or if a
redraw is forced by resizing or iconifying/deiconifying the
window.





This bug can be reproduced always.

---------- BEGIN SOURCE ----------
import java.awt.*;

/**
* Demonstrates a bug in the java.awt.TextArea class.
* @author Mirko Raner, PTSC
* @version 1.0 (2002-03-08)
**/
public class TextAreaBug
{
	public static void main(String[] arg)
	{
		Frame frame = new Frame();
		TextArea text = new TextArea();
		frame.add(text);
		frame.pack();
		frame.setVisible(true);

		String string;
		string = "This line will be fine.\r\n";
		string += "This line will be messed up.";
		for (int index = 0; index < string.length(); index++)
		{
			text.append(string.substring(index, index+1));
		}
	}
}


---------- END SOURCE ----------

CUSTOMER WORKAROUND :
A redraw can be forced programatically with setVisible
(false); setVisible(true), but that is not an acceptable
workaround in many cases, because it produces and annoying
flicker and also makes the caret disappear.

Release Regression From : 1.3.1_03
The above release value was the last known release where this 
bug was known to work. Since then there has been a regression.

(Review ID: 143946) 
======================================================================

Comments
CONVERTED DATA BugTraq+ Release Management Values COMMIT TO FIX: mantis FIXED IN: mantis INTEGRATED IN: mantis
14-06-2004

SUGGESTED FIX Name: dkR10074 Date: 08/01/2002 Please see a suggested fix for 4701398. ###@###.### 2002-08-01 ======================================================================
01-08-2002

EVALUATION Related to 4652358? ###@###.### 2002-04-11 Name: dmR10075 Date: 04/17/2002 The problem is in handling of the lone standing '\r' character in RichEdit on these platforms. Win2000: On both cases editor counts this symbols as character - you can move caret through it - so, for example, if we add 'abcd\r' in the text editor and move cursor(by 'cursor' I mean the position of text insertion, on Win32 it is also the start of the selection, caret is mostly painted at the cursor's position) to the end, then press Left to move it one character back - caret will not move because \r before caret. Press Left once again - we passed \r - and caret will shift one character left. On this platform editor treats '\r' as the character of ZERO width, so it doesn't affect caret position when text caret position is changing - cursor position before and after \r corresponds to one caret position. Win98: Here is the difference: \r has NON-ZERO width, it looks and affects caret absolutely like space character. This wouldn't cause any troubles if it is just like we replaced \r with space. But \r has special semantic regarding selection - it has zero length on both platforms when the length (or selection, cursor position) is calculated. So, what happens on Win98: Let's say we have some text in editor 'abcd', So, caret is 4, cursor is 4. Then we add '\r' and 'e'. After we inserted \r both cursor and caret both have changed their values - caret is 5(non zero width), cursor is 5. Then we add 'e': it treats selection position not as 5, no, it inserts 'e' into 4th position, it also updates caret - it is on 6 position, and (!!!) invalidates text being affected i.e. 6th character from the start, i.e. the part of the screen where \r is currently being drawn. The part of the screen where 'e' is being inserted is not being invalidated. Don't know why but white space by itself is the trigger to repaint the upcoming character, may be because it is painted differently than other characters (not using text output functions) so that's why we see the first letters in the test. If we remove \n from the test then the first 'T' from 'This' also will not be painted as there will not be 'trigger character' before it. That how I understand what's going on. One of the ways to fix is just to delete \r if it is on the end of the string being added to editor. Or we can just delete all \r us they have no use in editor - on Win2000 they don't occupy any space but cursor stops on them as on regular character, it looks like some obstacle on the path of the cursor - which is ugly. I prefer the second - to delete lone standing '\r'(not followed by \n) from the text being passed to the native control. ###@###.### 2002-04-17 ====================================================================== Name: dkR10074 Date: 08/01/2002 Please see an evaluation for 4701398. ###@###.### 2002-08-01 ======================================================================
01-08-2002