RichTextArea undo style ContentChange

[Jurgen Doll]

Hi Andy

A further note to clarify the side effect of the undo bug, where ContentChange.isEdit returns true when it should be false.
In my application it revolves around spellchecking. When the user "pauses" typing, spell check runs and marks any bad words. Currently if the user invokes undo then the markup is removed (as it was the last change) but because ContentChange.isEdit returns true (instead of false) the spellcheck runs and immediately marks the bad word again.
The root cause of this bug starts in StyledTextModel.applyStyle:766 where an UndoableChange object is created. The problem is that UndoableChange needs to know that this is a style change edit so that when UndoableChange.undo() is invoked it can call model.applyStyle(....) instead of model.replace(....)
Could you please file a bug report for this.
Thanks, regards
Jurgen

On Oct 31 2025, at 9:01 am, Jurgen Doll <jurgen at ivoryemr.co.za> wrote:
> Hi Andy
>
> Just to be clear, my main purpose was to report the undo bug. It occurs when either setStyle or applyStyle are invoked and then undo is called afterwards. The problem is that ContentChange.undo invokes model.replace(....) which is incorrect in this case, where as it should be model.applyStyle(....) because the former results in an event being fired where ContentChange.isEdit returns true when it should be false.
> Also to be clear I have no problem with your current PR, it makes sense. I'm not advocating for stopping or changing it :-)
> Here's a use case for styling: imagine an editor, like an IDE maybe, that has a search function that highlights all matching words. We'd like those highlights to remain in place even if undo/redo actions are called. That is the user doesn't expect the highlights to disappear on surrounding matches if undo is invoked on their last edit.
> I think allowing styling to behave in this way is safe because it doesn't change the structure of the document, only it's appearance, so the structural state of the document is always consistant.
> Thanks, regards
> Jurgen
>
>
> On Oct 30 2025, at 7:14 pm, Andy Goryachev <andy.goryachev at oracle.com> wrote:
> > Jurgen:
> >
> > Thanks for the feedback! The main reason I've decided to remove this parameter is that selectively disabling / enabling undo functionality messes up the internal state.
> >
> > Perhaps, when the application edits/styles the document on its own, it should do it in steps - for example, I noticed that Apple Notes allows the user to undo the auto-format like bulleted list (I think MS Word does a similar thing). Also, there is currently no way to coalesce undo records (see https://bugs.openjdk.org/browse/JDK-8370447 ) and no API to allow the model to customize the process.
> >
> > I do want to understand your use case - can you explain it in more detail please? Give me an example of the expected behavior?
> >
> > Thanks!
> > -andy
> >
> > From: openjfx-discuss <openjfx-discuss-retn at openjdk.org> on behalf of Jurgen Doll <jurgen at ivoryemr.co.za>
> > Date: Thursday, October 30, 2025 at 09:35
> > To: openjfx-discuss at openjdk.org <openjfx-discuss at openjdk.org>
> > Subject: RichTextArea undo style ContentChange
> >
> > Hi Andy
> >
> > In view of your current "remove allowUndo parameter" PR, I took another look at why I requested that applyStyle and setStyle also have that parameter. Part of the reason, I have now discovered, is due to a bug in the way that undo is processed.
> >
> > Basically when undoing a STYLE ONLY change an event is fired where ContentChange.isEdit returns true when it should be false. To fix, I think that the UndoableChange.create() method needs a styleOnly flag (or maybe another method needs to be added for style only changes). Then when the UndoableChange.undo method is called it can invoke model.applyStyle() with appropriate values instead of model.replace() which will then trigger the correct event.
> >
> > Note that even with this fixed though, it might still be desirable to be able to add/remove styling with an undo parameter. The use case I have is that only user styling actions are on the undo stack but programmatic changes for spellchecking or other markup are skipped if desired. The effect this has is that when the user undoes something it's directly related to what they have just done and not what the program has done.
> >
> > Thanks, regards
> > Jurgen
> >
>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-discuss/attachments/20251031/0b3350b5/attachment-0001.htm>