JDK-4800187 : REGRESSION:show the wrong selection when there are \r characters in the text
  • Type: Bug
  • Component: client-libs
  • Sub-Component: java.awt
  • Affected Version: 1.4.2
  • Priority: P2
  • Status: Resolved
  • Resolution: Fixed
  • OS: windows_xp
  • CPU: x86
  • Submitted: 2003-01-08
  • Updated: 2003-03-04
  • Resolved: 2003-03-04
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.
1.4.2 b18Fixed
###@###.### 2003-01-08

I can not reproduce this problem on my WinXP, Win2K with English locale.
Just log this bug in case engineer team be able to reproduce the problem 
with nl_NL locale.

J2SE Version (please include all output from java -version flag):
  java version "1.4.2-beta"
  Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2-beta-b10)
  Java HotSpot(TM) Client VM (build 1.4.2-beta-b10, mixed mode)

Does this problem occur on J2SE 1.3 or 1.4?  Yes / No (pick one)

Operating System Configuration Information (be specific):
  Windows XP SP1 with nl_NL locale.

Hardware Configuration Information (be specific):
  IBM Thinkpad A20p, 384Mb ram

Bug Description:
  setSelectionStart/setSelectionEnd) show the wrong selection when there
  are \r characters in the text. 

Steps to Reproduce (be specific):
  Run the sample(MantisAwtBugs.java) using 1.4.2 and click on the left button.
  You'll see that the visual selection doesn't correspond to the text that 
  gets copied. (check screen shot mbug.jpg)

CONVERTED DATA BugTraq+ Release Management Values COMMIT TO FIX: mantis-beta tiger FIXED IN: mantis-beta tiger INTEGRATED IN: mantis-b18 mantis-beta tiger tiger-b03

EVALUATION Commit to fix in Tiger (regression, CAP). ###@###.### 2003-01-08 I can reproduce the problem in English Locale on Windows XP SP1. I can also reproduce it on Windows 2000. I found that the problem starts in b08. This coincides with our change to RichEdit 2.0. ###@###.### 2003-01-16 I can also reproduce it on Win NT 4.0 and Win98 Second Edition. I was not able t o find an ME machine, but I suspect it will be reproducible on ME as well. ###@###.### 2003-01-16 I can reproduce the problem in the US English locale on Windows NT. I hit the button at the bottom of the app to select text. The selected text is wrong, but the right text is transferred to the TextArea on the right side of the app. This bug is reproducible in all locales and platforms we have tried. ###@###.### 2003-01-16 Name: dkR10074 Date: 02/27/2003 Ideally, we would like to have our text components working the same way on all supported platforms. It would be nice to reduce the implementation-dependant "features" of their behavior to a minimum. On Solaris, we have exactly that. In other words, we'd like to have: - getText() returns exactly what we pass to setText(). - line separators have no effect on correct work of methods like select(), setSelectionStart(), setSelectionEnd() and getSelectedText(). - text components handle correctly both \r\n and \n separators. - s1 equals s2 after execution of the following code: int start = 15; int end = 30; textArea.select(start, end); String s1 = textArea.getSelectedText(); String s2 = textArea.getText().substring(start, end); if (s1.equals(s2)) { // cool } - \r, if it isn't a part of line separator, is considered a control symbol and is displayed as a square or blank. Or, if it is a part of line separator, it is not displayed at all. Trying to implement this behavior on Windows using RichEdit, we come across the following problems: - RichEdit behavior depends on its version. Currently we use RichEdit v1.0 on Win95 and RichEdit v2.0 on other Windows versions. - RichEdit's "intelligence": it replaces single \r by line separator. - RichEdit normalizes line separators. Depending on called functions, it can replace \n by \r\n sequence, or vice versa. We work with the first option, using functions GetWindowText/SetWindowText. - RichEdit considers the length of line separator equal to 1 while computing the bounds of selected block. Because of these RichEdit's features, getText() cannot return exactly the same text that is passed to setText() if both \r\n and \n are used as line separators. Taking into consideration the differences between desired behavior and RichEdit's behavior, we can come up with the following possible fixes of our problem: 1. Currently we already remove any single \r we meet, only leaving it intact if it is a part of line separator (see the fix for 4701398). We can remove all \r's, only leaving \n as a line separator. 2. We can assume that line separator length is equal to 1, and also assume that the user will do the same. We'll have to modify getJavaSelPos() and getWin32SelPos() slightly. 3. We can assume that line separator length is equal to 1, and also assume that the user will do the same. This way, we can implement automatic detection of which form line separator has. The suggested fix is based on the 3rd option. Actually, it looks like the best way to fix the bug. Probably, it requires changes to either doc or Release Notes. Also, we need to declare \r removal in text components and ask users to work with \n or line.separator property and keep in mind that line separator length is equal to 1, even if it is 2. ###@###.### 2003-02-27 ======================================================================