Last Comment Bug 458524 - add mechanism for editing libraries to make changes separately from the undo/redo stack (Automatic syntax highlighting interferes with undo/redo history in rich text editors)
: add mechanism for editing libraries to make changes separately from the undo/...
Status: NEW
Product: Core
Classification: Components
Component: Editor (show other bugs)
: unspecified
: x86 Windows XP
-- enhancement with 122 votes (vote)
: ---
Assigned To: Nobody; OK to take it and work on it
: Makoto Kato [:m_kato]
Depends on:
  Show dependency treegraph
Reported: 2008-10-04 11:23 PDT by Cacycle
Modified: 2014-07-03 08:22 PDT (History)
16 users (show)
roc: blocking1.9.2-
roc: wanted1.9.2-
See Also:
Crash Signature:
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Description User image Cacycle 2008-10-04 11:23:45 PDT
User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv: Gecko/20080201 Firefox/
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv: Gecko/20080201 Firefox/

In JavaScript rich text editors it is currently not possible to do background text formatting (e.g. syntax highlighting) without disrupting the undo/redo functionality.
The reason is that every automatic change that goes through the execCommand interface results in one step in the undo/redo history while any automatic change through DOM manipulation completely erases that history. Both options are not acceptable for the user.

This is currently a major hurdle in the development of many rich text editors (including the Wikipedia editor wikEd

I am not familiar with Midas implementation details but one possible solution might be:

- Automatic changes are usually submitted after automatic highlighting (setting a range) followed by a inserthtml command. The undo/redo function merges manual text changes that do not involve caret movements. It might be possible to merge  all inserthtml changes that do not involve plain text changes with the current undo step.
- Alternatively, a new option (or even a new command) could be added to force such a redo merge

It would be great if we could discuss ways to fix this in this thread and could come up with a solution.

Reproducible: Always
Comment 1 User image ipatrol 2009-07-17 08:22:24 PDT
This is a problem and a major barrier for wikEd, which is used on many various wikis in order to improve their user's experience. Rich text editors for things like blogs are also exist and this bug interferes with them as well.
Comment 2 User image pfisher 2009-08-27 15:09:10 PDT
Yes, if you fix this, you can really help out wikipedia.
Comment 3 User image David Baron :dbaron: 🏴󠁵󠁳󠁣󠁡󠁿 ⌚UTC-7 (if account gets disabled due to email bounces, ask a bugzilla admin to reenable it) 2009-09-08 13:30:43 PDT
Do other browsers do better here?  If so, how?  If not, it seems like changing our behavior might pose compatibility problems, and a better forum for developing a solution might be the WHATWG list.
Comment 4 User image Cacycle 2009-09-08 15:44:44 PDT
The others do not do better as far as I know.

I agree that the introduction of new options and commands should finally be discussed and decided by WHATWG or another standardizing instance. However, it would not hurt to brainstorm some possible solutions here first with people that know more about the actual details of the Midas implementation.

Some of the possible solutions (or at least temporary fixes) proposed above lay at the discretion of of the browser implementations and it is hard to imagine how the fine tuning of the undo/redo functionality could introduce unwanted browser incompatibilities.
Comment 5 User image David 2010-02-16 05:54:40 PST
I know very little about the programing end of things but I do know that as a Wikipedia editor, the project WikEd that Cacycle is working on is the best thing since sliced bread. Such text editors are the future for Wiki projects.

Note You need to log in before you can comment on or make changes to this bug.