Closed Bug 609821 Opened 15 years ago Closed 15 years ago

"ASSERTION: frame must not be dirty" (nsIFrame::GetCaretBaseline) causing crashtests/420439.html | assertion count 1 is more than expected 0

Categories

(Core :: DOM: Editor, defect)

x86
macOS
defect
Not set
normal

Tracking

()

RESOLVED FIXED
mozilla2.0b8

People

(Reporter: jruderman, Assigned: ehsan.akhgari)

References

Details

(4 keywords)

Attachments

(3 files)

This just started happening today. I'm guessing it's a regression from http://hg.mozilla.org/mozilla-central/rev/ed0befc22bb7 (bug 389321 part 3), which added GetCaretBaseline.
Attached file stack trace
###!!! ASSERTION: frame must not be dirty: '!NS_SUBTREE_DIRTY(this)', file layout/generic/nsFrame.cpp, line 909 nsFrame::GetBaseline [layout/generic/nsFrame.cpp:912] nsIFrame::GetCaretBaseline [layout/generic/nsIFrame.h:987] nsCaret::GetGeometryForFrame [layout/base/nsCaret.cpp:368] ...
I think bug 607857 would probably fix this.
http://tinderbox.mozilla.org/showlog.cgi?log=Firefox/1288947511.1288947890.22494.gz&fulltext=1 Rev3 Fedora 12 mozilla-central debug test crashtest on 2010/11/05 01:58:31 s: talos-r3-fed-007 REFTEST INFO | Loading a blank page WARNING: NS_ENSURE_TRUE(mDisabledJSAndPlugins) failed: file /builds/slave/mozilla-central-linux-debug/build/editor/composer/src/nsEditingSession.cpp, line 250 ###!!! ASSERTION: frame must not be dirty: '!NS_SUBTREE_DIRTY(this)', file /builds/slave/mozilla-central-linux-debug/build/layout/generic/nsFrame.cpp, line 909 nsFrame::GetBaseline [layout/generic/nsFrame.cpp:912] nsIFrame::GetCaretBaseline [layout/generic/nsIFrame.h:987] ... REFTEST TEST-UNEXPECTED-FAIL | file:///home/cltbld/talos-slave/mozilla-central_fedora-debug_test-crashtest/build/reftest/tests/editor/libeditor/html/crashtests/420439.html | assertion count 1 is more than expected 0 assertions
Blocks: 438871
Summary: "ASSERTION: frame must not be dirty" (nsIFrame::GetCaretBaseline) → "ASSERTION: frame must not be dirty" (nsIFrame::GetCaretBaseline) causing crashtests/420439.html | assertion count 1 is more than expected 0
Whiteboard: [orange]
(In reply to comment #3) > I think bug 607857 would probably fix this. I don't think so. GetPointFromOffset doesn't fail here, so bug 607857 should be a no-op as far as this assertion is concerned.
What's happening here is that nsTableCellFrame doesn't provide its own implementation of GetCaretBaseline, so we fall back to the default implementation in nsIFrame which calls GetBaseline. Now, nsTableCellFrame doesn't provide GetBaseline either, so we fall back to the nsFrame implementation which asserts that the subtree shouldn't be dirty. Now, this is a general problem, I think. PresShell::ProcessReflowCommands calls WillDoReflow, which tries to update the caret position *before* the reflow has happened. This means that there are probably many cases in which GetBaseline would assert in a similar way. I'm not sure why we have to update the caret position before reflow, since the reflow is likely to change the caret rect. Do we have a good reason to do that?
I think we need to call InvalidateOutsideCaret there, to make sure the right area is invalidated before the caret moves, but we don't need to call (and shoudn't call) UpdateCaretPosition.
I agree with what roc said above. FYI, the caret stuff in PresShell::WillDo/DidDoReflow was added in bug 334649.
BTW, I did submit a patch to TryServer yesterday with that fix and there's no errors so far. I also tested a bit manually and it seemed to work fine.
http://tinderbox.mozilla.org/showlog.cgi?log=SeaMonkey/1289093117.1289093812.11463.gz OS X 10.5 comm-central-trunk debug test crashtest on 2010/11/06 18:25:17 http://tinderbox.mozilla.org/showlog.cgi?log=SeaMonkey/1289125630.1289126106.3113.gz OS X 10.5 comm-central-trunk debug test crashtest on 2010/11/07 02:27:10 http://tinderbox.mozilla.org/showlog.cgi?log=SeaMonkey/1289134646.1289135437.23565.gz OS X 10.5 comm-central-trunk debug test crashtest on 2010/11/07 04:57:26
Attached patch Patch (v1)Splinter Review
Assignee: nobody → ehsan
Status: NEW → ASSIGNED
Attachment #489013 - Flags: review?(roc)
Attachment #489013 - Flags: approval2.0?
Attachment #489013 - Flags: approval2.0? → approval2.0+
Whiteboard: [orange] → [orange][needs landing]
Status: ASSIGNED → RESOLVED
Closed: 15 years ago
Flags: in-testsuite+
Resolution: --- → FIXED
Whiteboard: [orange][needs landing] → [orange]
Target Milestone: --- → mozilla2.0b8
Whiteboard: [orange]
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: