Closed Bug 407079 Opened 12 years ago Closed 9 years ago
"ASSERTION: selection not reset after deletion" with <textarea contenteditable> and exec
Loading the testcase triggers: ###!!! ASSERTION: selection not reset after deletion: 'testCollapsed', file /Users/jruderman/trunk/mozilla/editor/libeditor/base/nsEditor.cpp, line 4597
This is not a problem. The web page first execCommands SelectAll and then InsertHtml. But the SelectAll selects the entire document, the root of which is not editable, so the InsertHtml refuses to paste over top of that, and cancels (but not fails) its insertion. This does not change the selection. So the assertion that the selection should be collapsed fails, as we've still got the whole document selected. So we can either: 1. Remove the assertion, as it's assuming something that's not always true. 2. Change DeleteSelection() to take another parameter which tells us whether it cancelled the deletion, and then change the assertion such that it only assumes that the selection should be collapsed when the deletion was not cancelled. I favour #1 because it's easy. Occurs on Windows, OS->All. Adding Roc and PeterV for comment.
OS: Mac OS X → All
Shouldn't "Select All" just select everything in the current editable scope? (i.e. everything under the nearest non-editable ancestor)?
(In reply to comment #2) > Shouldn't "Select All" just select everything in the current editable scope? > (i.e. everything under the nearest non-editable ancestor)? > We define it to be that [http://developer.mozilla.org/en/docs/Rich-Text_Editing_in_Mozilla], but IE7 selects the entire page rather than the editable section [http://msdn2.microsoft.com/en-us/library/aa220275(office.11).aspx] (and I've verified this by testing too). Do we want to carry on matching IE, or do we want to change the SelectAll command to only select editable content? I think it makes sense to have select all select even non-editables, as you may want to copy them to clipboard.
I'm not hitting the assertion anymore. New bug for the behavior difference?
(In reply to comment #4) > I'm not hitting the assertion anymore. New bug for the behavior difference? Is there a good reason not to just morph this bug?
Fuzz bugs often have hidden dependencies ;) And a new bug can be clearer. I filed bug 613392.
Status: NEW → RESOLVED
Closed: 9 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.