Closed Bug 67363 Opened 24 years ago Closed 22 years ago

Undo should work for batch ReplaceAll

Categories

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

defect

Tracking

()

RESOLVED FIXED
mozilla1.2beta

People

(Reporter: sujay, Assigned: akkzilla)

References

()

Details

(Whiteboard: [behavior])

Attachments

(2 files, 1 obsolete file)

using 1/30 build of netscape 1) launch netscape 2) jump to above URL 3) File | Edit Page 4) Edit | Replace 5) replace "understanding" with "misunderstanding" with Wrap selected. 6) click OK. 7) Edit | Undo notice it only Undo's one replace instead of all 3 at the same time(batch). all platforms.
forgot to Cc: shrirang
This is real easy it's just a matter of extending nsITextServicesDocument to expose batching.
Status: NEW → ASSIGNED
Priority: -- → P3
Target Milestone: --- → mozilla0.9
moving to mozilla0.9.1
Target Milestone: mozilla0.9 → mozilla0.9.1
Target Milestone: mozilla0.9.1 → mozilla0.9.2
Keywords: correctness
Whiteboard: [behavior]
Target Milestone: mozilla0.9.2 → mozilla1.0
*** Bug 98769 has been marked as a duplicate of this bug. ***
Blocks: 106961
Bulk move of mozilla1.0 bugs to mozilla.1.0.1. I will try to pull some of these back in if I can.
Target Milestone: mozilla1.0 → mozilla1.0.1
Keywords: mozilla1.0+
Akkana: I'm re-assigning this to you since Kin says you have been working on this issue.
Assignee: kin → akkana
Status: ASSIGNED → NEW
not a mozilla 1.0 stopper
Keywords: mozilla1.0+mozilla1.0-
Target Milestone: mozilla1.0.1 → mozilla1.2beta
Blocks: 162592
Cc potential reviewers, patch coming.
Status: NEW → ASSIGNED
This does the trick. Question, though: should I worry about what happens if one of the intermediate operations throws an exception and the transaction never gets closed? It wouldn't be hard to wrap the whole replaceAll in a try{}, and close the transaction if we catch anything. I could also handle the couple of premature return cases that way -- throw a specific exception instead of closing the transaction and returning. Would that be better?
If you open a batch you need to close it, otherwise the editor will be stuck batching forever. I personally don't like throwing exceptions unless there is an error, but it's up to you ... calling endTransaction() at every return point is fine by me.
Thanks for the fast comment. Here's a new patch that wraps everything in a try so we'll be sure that the transaction will always be closed. I didn't throw from the two returns, just left them as endTransaction/return as in the previous patch. Since the try() meant reindenting the whole routine, the patch is a lot of lines. I'll attach a -w version to make reviews easier if you want to trust me on the formatting.
Attachment #99580 - Attachment is obsolete: true
Comment on attachment 99593 [details] [diff] [review] Same as last patch except using -w r=brade
Attachment #99593 - Flags: review+
Comment on attachment 99593 [details] [diff] [review] Same as last patch except using -w sr=kin@netscape.com
Attachment #99593 - Flags: superreview+
Fixed.
Status: ASSIGNED → RESOLVED
Closed: 22 years ago
Resolution: --- → FIXED
I thought that per the "Hacking Mozilla" page and the C++ portability page, exceptions can't be used: http://www.mozilla.org/hacking/portable-cpp.html#dont_use_exceptions
Bernard: did you look at the patch? It doesn't touch any C++ and doesn't use C++ exceptions in any way.
No longer blocks: 162592
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: