The default bug view has changed. See this FAQ.

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)

NEW
Unassigned

Status

()

Core
Editor
--
enhancement
9 years ago
3 years ago

People

(Reporter: Cacycle, Unassigned)

Tracking

unspecified
x86
Windows XP
Points:
---
Bug Flags:
blocking1.9.2 -
wanted1.9.2 -

Firefox Tracking Flags

(blocking2.0 -)

Details

(Reporter)

Description

9 years ago
User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.12) Gecko/20080201 Firefox/2.0.0.12
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.12) Gecko/20080201 Firefox/2.0.0.12

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 http://en.wikipedia.org/wiki/User:Cacycle/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

Updated

9 years ago
Component: General → Editor
Product: Firefox → Core
QA Contact: general → editor

Comment 1

8 years ago
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

8 years ago
Yes, if you fix this, you can really help out wikipedia.

Updated

8 years ago
Flags: wanted1.9.2?
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.
(Reporter)

Comment 4

8 years ago
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.
Flags: wanted1.9.2?
Flags: wanted1.9.2-
Flags: blocking1.9.2-

Comment 5

7 years ago
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.
blocking2.0: --- → ?
Summary: Automatic syntax highlighting interferes with undo/redo history in rich text editors → 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)
Status: UNCONFIRMED → NEW
Ever confirmed: true
blocking2.0: ? → -
You need to log in before you can comment on or make changes to this bug.