476579 - "ASSERTION: nsTableCellMap::RemoveCell - could not remove cell" with -moz-column

Status: RESOLVED DUPLICATE of bug 468771

(Core :: Layout: Tables, defect)

Description

[Jesse Ruderman]

Attachment: testcase

###!!! ASSERTION: nsTableCellMap::RemoveCell - could not remove cell: 'Error', file /Users/jruderman/central/layout/tables/nsCellMap.cpp, line 724

Crash [@ BasicTableLayoutStrategy::ComputeColumnIntrinsicWidths] calling 0x00000000.

Security-sensitive because 0x00000000 is called (not simply accessed).

Comment 1

[Jesse Ruderman]

Oh, and I've seen this call 0xdddddddd.

Comment 2

[Bernd]

I will look into this.

Comment 3

[Bernd]

Martijn,

is this a regression?

Bernd

Comment 4

[Martijn Wargers (dead)]

This regressed between 2008-02-10 and 2008-02-12:
http://bonsai.mozilla.org/cvsquery.cgi?treeid=default&module=all&branch=HEAD&branchtype=match&dir=&file=&filetype=match&who=&whotype=match&sortby=Date&hours=2&date=explicit&mindate=2008-02-10+04%3A00%3A00&maxdate=2008-02-12+09%3A00%3A00&cvsroot=%2Fcvsroot
Regression from bug 400813.
Related to bug 473410 and/or bug 463350?

Comment 5

[Bernd]

If comment 0 would have mentioned 
###!!! ASSERTION: Shouldn't be incomplete if availableHeight is UNCONSTRAINED.: 'aReflowState.availableHeight != NS_UNCONSTRAINEDSIZE', file d:/moz_src/src/layout/generic/nsBlockFrame.cpp, line 1400

I would not even have bothered to ask for a regression range. Its a known old melody.

Comment 6

[Bernd]

see bug 468771 for example

Comment 7

[Bernd]

Attachment: testcase that only asserts

The testcase triggers only the incomplete assert.

Comment 8

[Bernd]

Attachment: reflow log

please notice that during the problematic reflow a h-resize v-resize on the column frame is executed, however the nif of the incomplete first block is not queried but the status of the first block is returned instead of the complete status of the nif.

Comment 9

[Bernd]

Attachment: add some debug info that other frames also provide

Comment 10

[Bernd]

Attachment: reflow log

so what happens here is that block above the columnset which later gets removed indicates enough space so that two columns would fit.

Since the text "s t" does not fit into a single column two columns are populated. 
After the mutation only 1px wide column is reported as pref width. Since the column set does not ask for more space its gets only 1px as available space. So into this only one column fits.

And then IMHO the block reflow borks

instead of  showing something like

ColumnSet(div)(0) 06FB570C Reflow a=60,UC c=60,UC dirty v-resize cnt=11907 
            block 06FB5658 Reflow a=60,UC c=60,UC dirty v-resize cnt=11908 
             text 06FB58D4 Reflow a=60,UC c=UC,UC dirty v-resize nif=06FB6448 cnt=11909 
             text 06FB58D4 Reflow d=360,1140 status=0x1
             text 06FB6448 Reflow a=60,UC c=UC,UC dirty v-resize pif=06FB58D4 cnt=11910 
             text 06FB6448 Reflow d=240,1140 
            block 06FB5658 Reflow d=60,2400 o=(0,0) 360 x 2400sto=(0,0) 360 x 2400
           ColumnSet(div)(0) 06FB570C Reflow d=60,2400 o=(0,0) 360 x 2400sto=(0,0) 360 x 2400

it does not show a 2400 twips height but as previously 1140twips because the outer block still has its nextinflow from the previous 2 column scenario which would easily take care of the 2 second letter.

summary: the number of columns shrinks but the old nextinflows should be adapted to this (removed??).

Comment 11

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Fixed by the patch in bug 468771.

Comment 12

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Fixed by checkin for bug 468771.