Bug 26888 - JTextArea/PlainDocument - removing text with line-breaks makes component unusable
Summary: JTextArea/PlainDocument - removing text with line-breaks makes component unus...
Status: RESOLVED FIXED
Alias: None
Product: classpath
Classification: Unclassified
Component: swing (show other bugs)
Version: 0.90
: P3 normal
Target Milestone: 0.91
Assignee: Robert Schuster
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2006-03-27 16:59 UTC by Robert Schuster
Modified: 2006-03-29 15:29 UTC (History)
1 user (show)

See Also:
Host:
Target:
Build:
Known to work:
Known to fail:
Last reconfirmed: 2006-03-29 14:24:17


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Robert Schuster 2006-03-27 16:59:01 UTC
Enter the following text into a JTextArea (without quotes):

"abc
def"

Move before the a and delete all characters by pressing the delete key. If you press a key now nothing will happen, eg. no text is put into the textarea. Pasting while having a text in the clipboard does not work either.

Explicitly setting a text with jTextAreaInstance.setText("foo") does not work, too.

Getting the underlying PlainDocument and running insertString(0, "foo", null) has no effect, too.
Comment 1 Robert Schuster 2006-03-27 22:31:46 UTC
An empty PlainDocument.dump() prints the following:

<paragraph>
  <content>
    [0,1][
]

After inserting "a" at offset 0 the same method prints:
<paragraph>
  <content>
    [0,2][a
]
  <content>
    [1,2][
]

Which is wrong. After doing a manual plainDocument.reindex() the correct result is:
<paragraph>
  <content>
    [0,2][a
]

A fix for this PR should handle this problem, too.

Comment 2 Robert Schuster 2006-03-29 14:24:17 UTC
The last message is bogus. The problem which was observed with a slightly tweaked version of PlainDocument and that tweak introduced the problem.

----

I found out that the problem is caused by a strange behavior of the GapContent class. Consider GapContent is in the following state:

gapStart: 0
gapEnd: 1
Position object at b: mark = 2
<..>bc

Now if a single character ('z') is inserted. The GapContent turns into this state:
gapStart: 1
gapEnd: 1
Position object at b: mark = 2
z<.>bc

Since the gap became smaller (gapEnd - gapStart is 0) the offset of the position object changes from 0 to 1. If such an Position object marks the beginning of the first Element in a PlainDocument that is wrong. The offset should not change.

The fix for this problem is to add a call to resetMarksAtZero() after copying the new characters into the buffer of GapContent (in replace()).

The code will look like this afterards:

...

if (addItems != null)
      {
        System.arraycopy(addItems, 0, buffer, gapStart, addSize);
        resetMarksAtZero();
        gapStart += addSize;
      }

...
Comment 3 cvs-commit@developer.classpath.org 2006-03-29 14:53:13 UTC
Subject: Bug 26888

CVSROOT:	/cvsroot/classpath
Module name:	classpath
Branch: 	
Changes by:	Robert Schuster <rschuster@savannah.gnu.org>	06/03/29 14:52:35

Modified files:
	.              : ChangeLog 
	javax/swing/text: GapContent.java 

Log message:
	Fixes PR 26888.
	
	2006-03-29  Robert Schuster  <robertschuster@fsfe.org>
	
	PR 26888
	* javax/swing/text/GapContent.java:
	(replace): Added call to resetMarksAtZero.

CVSWeb URLs:
http://cvs.savannah.gnu.org/viewcvs/classpath/classpath/ChangeLog.diff?tr1=1.6940&tr2=1.6941&r1=text&r2=text
http://cvs.savannah.gnu.org/viewcvs/classpath/classpath/javax/swing/text/GapContent.java.diff?tr1=1.42&tr2=1.43&r1=text&r2=text



Comment 4 Robert Schuster 2006-03-29 14:57:21 UTC
Fix checked in.
Comment 5 Robert Schuster 2006-03-29 15:29:09 UTC
There is now a test in mauve for this issue: gnu.testlet.javax.swing.text.GapContent.insertString.testSpecialInsert()