It appears that when an incremental reflow is done on the table because of a style change, that the table destroys the cell map, but then upon recreation of the cell map, it doesn't bother to get the column frames back into the map. This results in a crash when you try to compute the vertical collapsing borders, because that function tries to pull out a column frame from the cell map (and fails). At first I thought this had to do with me using XML, but it appears the problem is actually with the table code. The relevant place to look is near the top of nsTableFrame::Reflow at the following code snippet: if (eReflowReason_Initial!=aReflowState.reason && PR_FALSE==IsCellMapValid()) { if (PR_TRUE==gsDebug || PR_TRUE==gsDebugIR) printf("TIF Reflow: cell map invalid, rebuilding...\n"); if (nsnull!=mCellMap) delete mCellMap; mCellMap = new nsCellMap(0,0); ReBuildCellMap(); #ifdef NS_DEBUG if (PR_TRUE==gsDebugIR) { DumpCellMap(); printf("tableFrame thinks colCount is %d\n", mEffectiveColCount); } #endif needsRecalc=PR_TRUE; } This code (when an incremental reflow occurs) deletes the cell map and recreates it, and the new cell map I get no longer has the column frames in it.

Chris is working towards feature-complete for tables, so I'll look into this bug.

Can you give me a test case? Is the style change actually happening on the table itself, or one of the table components (row, cell, etc.)? Does it matter what style attribute is changed, or what value that attribute is set to?

Something about the bug report is odd. (No, not the submitter.) The claim is that processing a style changed notification by the table frame causes the cellmap to be rebuilt incorrectly. Problem is, style changed handling doesn't touch the cell map. The relevant code (simplified) is: nsTableFrame::IR_StyleChanged(...) { InvalidateFirstPassCache(); return NS_OK; } Invalidating the first pass cache causes a full 2-step reflow, but not a rebuilding of the cell map. And at least for simple cases (like changing the table's width) I verified that the cell map remains intact. I also verified that the cell map doesn't change if you change style on a rowgroup, row, or cell. So something else must be going on here. A test case would help a lot.

Didactic aside: You can verify changes in the cell map as a result of incremental reflow by adding a call to DumpCellMap() in nsTableFrame::Reflow(), just before the return at the end of the method.

Setting all current Open Critical and Major to M3

per leger, assigning QA contacts to all open bugs without QA contacts according to list at http://bugzilla.mozilla.org/describecomponents.cgi?product=Browser

i propose that this get moved to M4. I don't think it's currently blocking any dogfood feature. Is that correct, David? I have a partial fix that I am uncomfortable checking in without a lot more testing.

moving to M4

changed misc bugs to M6

setting my table bugs to M9

works for me. It's true this used to not work, but I believe changes long ago to incremental reflow have fixed it. Attaching a test case.

Using 8/5 Apprunner, verified fixed.