The DefaultStyledDocument.ElementBuffer is responsible for performing structural changes to the Document's element structure in response to content insertion/deletion/change. For example, when a new line with some text is inserted, this must be reflected in the element structure (a new paragraph element is created covering the new line). While doing so, the ElementBuffer must add instances of ElementEdit to a DefaultDocumentEvent, which describe which changes have been made to which elements. This event is later passed around the views, so they can update themselves according to the element changes. The problem I am seeing is that the ElementBuffer sometimes adds multiple ElementEdit instance for the same element to the DefaultDocumentEvent (for instance when the structural change means first removing some content, then adding some content). This is not right, because the DefaultDocumentEvent is specified to only store 1 ElementEdit per Element. So what happens is that a second addition of an ElementEdit replaces the first addition of another ElementEdit for the same element. This then confuses the views, since they don't know about the first change, resulting in strange AssertionErrors, ArrayIndexOutOfBounds and other nasty failures. The solution would be to somehow collapse edits together so that we really only have one ElementEdit per changed element. I am assigning this to you Tony because I know you work in this area anyway. I really don't have the time to fix this atm. My work request queue is really overflowed atm :-/. If you feel you also cannot fix this then feel free to re-assign it to me and I will see if I can fix this, it will have to wait a while though... /Roman
Created attachment 10270 [details] Testcase that shows the problem It's the line break that causes the problem. The line break ends up in StyledDocument trying to create a new paragraph view. This has to fracture the previous paragraph view. This fracturing adds to ElementChanges to the DocumentEvent, of which only the last one is 'remembered' and passed on to the views. When you run the testcase against CVS HEAD, you'll see the FlowView breaking on this.
I will take care of this. This is a tricky issue and now I'm already knee-deep into this stuff, I can just as well finish it off.
The testcase for this program no longer crashes, due to the recent work by Lillian and myself on DefaultStyledDocument and the ElementBuffer. However, the work is not yet complete. I'll close this bug and open new ones for anything that still doesn't work (we have lots of test cases) in a few days. We've already committed several Mauve tests (both passing and failing) that demonstrate the problems, I think this bug should be closed since the specific problem it illustrated no longer exists.
Alot of mauve tests are still failing due to Element fracturing. InsertFracture needs to be rewritten to use recursion. Right now, it is coded as a work-around and fails in many cases. I am looking at this right now.
Finally fixed!