Closed Bug 538466 Opened 12 years ago Closed 12 years ago

"ASSERTION: Wrong document somewhere" with contenteditable

Categories

(Core :: DOM: Editor, defect)

PowerPC
macOS
defect
Not set
normal

Tracking

()

RESOLVED FIXED
mozilla1.9.3a1

People

(Reporter: jruderman, Assigned: masayuki)

References

(Blocks 1 open bug)

Details

(Keywords: assertion, testcase)

Attachments

(1 file)

Bug 537041 is fixed, but this new testcase also triggers the same assertion.

###!!! ASSERTION: Wrong document somewhere: 'GetCurrentDoc() == aPresShell->GetDocument()', file /Users/jruderman/central/content/base/src/nsGenericElement.cpp, line 400
Well, the code in nsHTMLEditor::SelectAll just grabs the selection anchor node (which is in the textnode that's in the span that's in the paragraph that's in the body that's NOT in the document) and then calls GetSelectionRootContent() on it.  Then we assert.

I think we should probably just replace the assert in GetSelectionRootContent() with a check; fixing all the selection consumers who apparently feel that they can trust selections (when they actually can't) is too much hassle...

Masayuki, does that sound ok to you?  This is basically what bug 537041 comment 9 last sentence was about.
Did you think we should land nsGenericElement.cpp part of https://bugzilla.mozilla.org/attachment.cgi?id=419535&action=diff ?

If so, I think it's ok.
Yes, that's exactly what I think.  r=me if you want to do that, or I can put up the patch and ask you for review.  ;)  Let me know.
ok, looks like the current tinderbox is safe for landing, I'll land the patch's part with r=bz.
http://hg.mozilla.org/mozilla-central/rev/500e3dbc7d35

done.
Assignee: nobody → masayuki
Status: NEW → RESOLVED
Closed: 12 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla1.9.3a1
Thanks!
Depends on: 539531
You need to log in before you can comment on or make changes to this bug.