-
Bug
-
Resolution: Cannot Reproduce
-
P4
-
None
-
1.1.1alpha, 1.1.2
-
other, sparc
-
other, solaris_2.5.1
When text is entered into the TextArea either via pasting or the append() method, typing additional text at the end of the originally appended lines and they overlaying another window over the text area and then removing it results in visual loss of characters. Solaris only.
In other words, if:
1. Append some multiple lines of text to the TextArea with the append() method
2. Position the cursor at the end of one of the lines and type in a few characters.
3. Pop-up another window on top of the TextArea so that the area that's typed in is hidden behind the other window. (I'm referring to the window Z-ordering.)
4. Pop the window with the TextArea back to front.
5. Notice that (sometime) the last character that was typed in is missing. However, if the text is retrieved with getText(), the character is still there.
I've only observed this under Solaris. This bug is very obvious when using the ComposeDialog in HotJava Views, which uses the standard TextArea for text entry (please see bugid 4104687 for additional info).
If you have any problems reproducing it, I'd like to show it and work together to find a fix.
max.spivak@Eng 1998-02-23
============
I finally got the testcase that I wanted. Now it's easily reproducible anywhere. Basically, when the text is added to the TextArea via the append() method, the text should be separated with \r\n. When you then type some text on an existing line following the inserted text, then overlay a window on it, and then pop it back up, you'll see that the typed-in text shifted right one character, and the right-most character disappeared.
Run the test case:
1. click on "Create Dialog"
2. click on "Add Text"
3. position the cursor to the right of any line (try the "some" in the 2nd line)
4. type in a character sequence (and remember what you type)
5. pop a window over the dialog
6. pop the dlg back up
7. notice that the string that was typed in shifted right one character loosing the right-most character in the process.
Again, this is Solaris-only. (My guess is that it's in the Motif peer, how it handles \r\n terminated lines.)
max.spivak@Eng 1998-02-26
In other words, if:
1. Append some multiple lines of text to the TextArea with the append() method
2. Position the cursor at the end of one of the lines and type in a few characters.
3. Pop-up another window on top of the TextArea so that the area that's typed in is hidden behind the other window. (I'm referring to the window Z-ordering.)
4. Pop the window with the TextArea back to front.
5. Notice that (sometime) the last character that was typed in is missing. However, if the text is retrieved with getText(), the character is still there.
I've only observed this under Solaris. This bug is very obvious when using the ComposeDialog in HotJava Views, which uses the standard TextArea for text entry (please see bugid 4104687 for additional info).
If you have any problems reproducing it, I'd like to show it and work together to find a fix.
max.spivak@Eng 1998-02-23
============
I finally got the testcase that I wanted. Now it's easily reproducible anywhere. Basically, when the text is added to the TextArea via the append() method, the text should be separated with \r\n. When you then type some text on an existing line following the inserted text, then overlay a window on it, and then pop it back up, you'll see that the typed-in text shifted right one character, and the right-most character disappeared.
Run the test case:
1. click on "Create Dialog"
2. click on "Add Text"
3. position the cursor to the right of any line (try the "some" in the 2nd line)
4. type in a character sequence (and remember what you type)
5. pop a window over the dialog
6. pop the dlg back up
7. notice that the string that was typed in shifted right one character loosing the right-most character in the process.
Again, this is Solaris-only. (My guess is that it's in the Motif peer, how it handles \r\n terminated lines.)
max.spivak@Eng 1998-02-26