United StatesChange Country, Oracle Worldwide Web Sites Communities I am a... I want to...
Bug ID: JDK-4800187 REGRESSION:show the wrong selection when there are \r characters in the text
JDK-4800187 : REGRESSION:show the wrong selection when there are \r characters in the text

Details
Type:
Bug
Submit Date:
2003-01-08
Status:
Resolved
Updated Date:
2003-03-04
Project Name:
JDK
Resolved Date:
2003-03-04
Component:
client-libs
OS:
windows_xp
Sub-Component:
java.awt
CPU:
x86
Priority:
P2
Resolution:
Fixed
Affected Versions:
1.4.2
Fixed Versions:
1.4.2 (b18)

Related Reports
Backport:

Sub Tasks

Description
###@###.### 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)
  No

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)


                                    

Comments
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

======================================================================
                                     
2003-02-27
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


                                     
2004-06-14



Hardware and Software, Engineered to Work Together