JDK-4701398 : REGRESSION: TextArea.append does not work consistently with \r.
  • Type: Bug
  • Component: client-libs
  • Sub-Component: java.awt
  • Affected Version: 1.4.0
  • Priority: P3
  • Status: Resolved
  • Resolution: Fixed
  • OS: windows_2000
  • CPU: x86
  • Submitted: 2002-06-12
  • 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
Description

Name: jk109818			Date: 06/12/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 :Microsoft Windows 2000
[Version 5.00.2195]


A DESCRIPTION OF THE PROBLEM :
TextArea.append acts inconsistently in JDK 1.4 on
Windows2000.  The first \r has no effect; subsequent ones
act as a \n.  See test program for an example

REGRESSION.  Last worked in version 1.3

STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
1.Run test program.  First time a button is pressed, the
output is on one line.
2.Subsequent presses give results on a new line
3.

EXPECTED VERSUS ACTUAL BEHAVIOR :
I would expect the output to be the same every time an
append was made.  If \r is not supported in an AWT
TextArea, it should give a box or something every time,
rather than acting as a \n sometimes and as nothing others.

This bug can be reproduced always.

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

public class BugTest extends Frame
	implements WindowListener , ActionListener  {
	public static void main(String args[]) {
		BugTest _BugTest__ = new BugTest();
		_BugTest__.pack();
		_BugTest__.show();
	}

	Button returnBug = new Button("returnBug");
	TextArea text = new TextArea("",10,40,TextArea.SCROLLBARS_BOTH);
	Panel border1 = new Panel(new BorderLayout(5,5));
	int i=0;

	public BugTest() {
		super("main0");
		this.setResizable(true);
		this.addWindowListener(this);
		returnBug.addActionListener(this);
		border1.add("North",returnBug);
		border1.add("Center",text);
		add("Center",border1);
	}

	public void windowActivated(WindowEvent evt) {}
	public void windowClosed(WindowEvent evt) {}

	public void windowClosing(WindowEvent evt) {
		this.dispose();
	}

	public void windowDeactivated(WindowEvent evt) {}
	public void windowDeiconified(WindowEvent evt) {}
	public void windowIconified(WindowEvent evt) {}
	public void windowOpened(WindowEvent evt) {}

	public void actionPerformed(ActionEvent evt) {
		if ( evt.getSource() == returnBug ) {
			text.append("newText"+(i++)+"\r");
			text.append("newText"+(i++)+"\r");
		}
	}
}

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

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: 143698) 
======================================================================

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

EVALUATION Probably the same issue as: 4652358, 4666876 ###@###.### 2002-06-12 Name: dkR10074 Date: 08/01/2002 Here is a whole group of almost identical bugs that can be fixed by the common fix. These bugs are: 4701398 (this bug), 4652358, 4659958, 4697796, 4666876. I am going to update the "Evaluation" and "Suggested Fix" fields for this bug report only. Others will have a link to this one. These bugs are reproducible because of a couple of methods that were destined for adding/removing the CR symbol (AddCR and RemoveCR) into/from a text of a text component. AddCR method works incorrectly. I think we do not need this method (AddCR) at all. Moreover, I think we should remove \r's from a text string when the string is inserted into a text component. That is needed because \r is interpreted differently on different versions of Windows (see 4666876). Removing all \r's will work better and more consistently across Windows versions. Furthermore, in this case the behavior of the text components on Windows will be the same as on Solaris. The fix is based on the removing the AddCR method at all and modifying the RemoveCR method to eliminate \r's from the inserted text string. ###@###.### 2002-08-01 ====================================================================== Name: dkR10074 Date: 08/09/2002 A problem has been found last moment that manifests by failing a regression test on the machines with Windows 2000 installed where the latest SP is not installed. I have investigated the problem and found that it is related with an old version of riched20.dll (5.30.23.1200), which has a couple of bugs (fixed in later versions, i.e 5.30.23.1209). The rich edit control 5.30.23.1200 translates each single \n to the sequence \r\n, so the regression test fails. The version 5.30.23.1209 does not translate \n's. I have modified the fix. Now RemoveCR removes single \r's only and the sequences \r\n keeps as is. ###@###.### 2002-08-09 ======================================================================
09-08-2002