Closed Bug 423514 Opened 17 years ago Closed 17 years ago

"ASSERTION: cellmap is lying" with rowspan, contenteditable, rtl

Categories

(Core :: Layout: Tables, defect)

x86
macOS
defect
Not set
normal

Tracking

()

RESOLVED FIXED

People

(Reporter: jruderman, Assigned: bernd_mozilla)

References

Details

(Keywords: assertion, rtl, testcase)

Attachments

(2 files)

491 bytes, application/xhtml+xml
Details
1.02 KB, text/plain
bzbarsky
: review+
bzbarsky
: superreview+
beltzner
: approval1.9+
Details
Attached file testcase
The testcase triggers this assertion a few times when it is loaded, and then again every time the caret blinks. ###!!! ASSERTION: cellmap is lying: 'Error', file /Users/jruderman/trunk/mozilla/layout/tables/nsTableRowGroupFrame.cpp, line 1675 This assertion was added by the patch in bug 388700.
once cvs is up again I will attach a patch that will change the code to *aNumFramesOnLine = cellMap->GetNumCellsOriginatingInRow(aLineNumber); if (*aNumFramesOnLine == 0) { return NS_OK; } PRInt32 colCount = table->GetColCount(); <<< we need this for (PRInt32 i = 0; i < colCount; i++) { Otherwise we have in the first cell a rowspan from above and will not lookup the second cell where the originating cell that made aNumFramesOnLine to be 1 will be found.
Attached file patch
Assignee: nobody → bernd_mozilla
Status: NEW → ASSIGNED
Attachment #310539 - Flags: superreview?(bzbarsky)
Attachment #310539 - Flags: review?(bzbarsky)
Comment on attachment 310539 [details] patch Indeed. r+sr=bzbarsky
Attachment #310539 - Flags: superreview?(bzbarsky)
Attachment #310539 - Flags: superreview+
Attachment #310539 - Flags: review?(bzbarsky)
Attachment #310539 - Flags: review+
Comment on attachment 310539 [details] patch this change is low risk and corrects a obviously wrong code.
Attachment #310539 - Flags: approval1.9?
Comment on attachment 310539 [details] patch a1.9=beltzner
Attachment #310539 - Flags: approval1.9? → approval1.9+
Flags: in-testsuite?
fix checked in
Status: ASSIGNED → RESOLVED
Closed: 17 years ago
Resolution: --- → FIXED
I checked in the testcase (with a change to make it wait 1200ms so the caret can blink) as a crashtest.
Flags: in-testsuite? → in-testsuite+
If this test depends on the caret blink time, can we add a comment where that blink time is defined saying so?
Caret blink time seems to be OS-dependent based on a skim of http://lxr.mozilla.org/mozilla/search?string=caretblink. I pulled "1200ms" out of thin air.
Ah, hmm. I wonder whether we can write some reftests that use != to make sure the caret is in fact blinking or something.... Seems difficult. :(
You can't currently, because canvas.drawWindow doesn't ever draw the caret.
(In reply to comment #11) > You can't currently, because canvas.drawWindow doesn't ever draw the caret. Well, that became worksforme, see bug 394763.
bug 426708 seems to be related to this bug
Depends on: 426708
Mass-assigning the new rtl keyword to RTL-related (see bug 349193).
Keywords: rtl
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: