Closed Bug 204793 Opened 21 years ago Closed 3 years ago

Editors need procedure for using alternate TxMgr

Categories

(Core :: DOM: Editor, defect, P5)

x86
Windows 98
defect

Tracking

()

RESOLVED WONTFIX

People

(Reporter: WeirdAl, Unassigned)

Details

Under certain conditions, it may be desirable for a text widget to use a
TransactionManager object other than the one it comes with by default.  For example:

* Bug 112922, DOM Inspector will want to make undo functionality work
identically inside the textarea as it currently does outside.

* Data entry services may want to have the ability to set undo/redo differently.

kin and I have had a long talk about what I, for hacking Inspector, intend this
for, and what I'm in particular looking for.  It may be best to provide a
function as a property of the html:input and html:textarea elements to tell the
widget to use an alternate TxMgr provided as an argument.
No longer blocks: 112922
I just realized this problem is more serious than I anticipated.  Fixing this
would allow for fixing a current bug in Composer's current undo/redo scheme.

Testcase:

(1) Start Composer.
(2) Normal view, type anything.
(3) Edit Menu, note Undo menu item is enabled.
(4) Switch to HTML Source view.
(5) Edit Menu, note Undo menu item is not enabled.
(6) Switch to any other view.
(7) Edit Menu, Undo menu item is enabled again.

Because there are two <xul:editor/> elements in Composer's UI,
(http://lxr.mozilla.org/seamonkey/source/editor/ui/composer/content/editor.xul#257
), the transactions do not seamlessly transfer between them as the actual
content does.

Having some sort of external txmgr for multiple editors would make this much,
much easier to fix.
Summary: Text inputs need procedure for using alternate TxMgr → Editors need procedure for using alternate TxMgr
Hm, a simple fix would be to change nsIEditor.transactionManager to not be read-only:

http://lxr.mozilla.org/seamonkey/source/editor/idl/nsIEditor.idl#192
QA Contact: bugzilla → editor
Assignee: mozeditor → nobody

Bulk-downgrade of unassigned, untouched DOM/Storage bug's priority.

If you have reason to believe, this is wrong, please write a comment and ni :jstutte.

Severity: normal → S4
Priority: -- → P5

Eighteen years and absolutely no interest. Yeah. This isn't going to happen.

Status: NEW → RESOLVED
Closed: 3 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.