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)
Tracking
()
RESOLVED
FIXED
mozilla2.0b8
People
(Reporter: jruderman, Assigned: ehsan.akhgari)
References
Details
(4 keywords)
Attachments
(3 files)
|
253 bytes,
application/xhtml+xml
|
Details | |
|
1.63 KB,
text/plain
|
Details | |
|
1.56 KB,
patch
|
roc
:
review+
benjamin
:
approval2.0+
|
Details | Diff | Splinter Review |
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.
| Reporter | ||
Comment 1•15 years ago
|
||
| Reporter | ||
Comment 2•15 years ago
|
||
###!!! 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]
...
Comment 3•15 years ago
|
||
I think bug 607857 would probably fix this.
Comment 4•15 years ago
|
||
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]
| Assignee | ||
Comment 5•15 years ago
|
||
(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.
| Assignee | ||
Comment 6•15 years ago
|
||
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.
Comment 8•15 years ago
|
||
I agree with what roc said above.
FYI, the caret stuff in PresShell::WillDo/DidDoReflow was added in bug 334649.
Comment 9•15 years ago
|
||
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.
Comment 10•15 years ago
|
||
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
| Comment hidden (Legacy TBPL/Treeherder Robot) |
| Assignee | ||
Comment 12•15 years ago
|
||
| Comment hidden (Legacy TBPL/Treeherder Robot) |
Attachment #489013 -
Flags: review?(roc) → review+
| Assignee | ||
Updated•15 years ago
|
Attachment #489013 -
Flags: approval2.0?
Updated•15 years ago
|
Attachment #489013 -
Flags: approval2.0? → approval2.0+
| Assignee | ||
Updated•15 years ago
|
Whiteboard: [orange] → [orange][needs landing]
| Assignee | ||
Comment 14•15 years ago
|
||
Status: ASSIGNED → RESOLVED
Closed: 15 years ago
Flags: in-testsuite+
Resolution: --- → FIXED
Whiteboard: [orange][needs landing] → [orange]
Target Milestone: --- → mozilla2.0b8
Updated•13 years ago
|
Keywords: intermittent-failure
Updated•13 years ago
|
Whiteboard: [orange]
You need to log in
before you can comment on or make changes to this bug.
Description
•