Build ID: 2006-02-23-09, SeaMonkey trunk on Windows XP. Summary: Tabbing inside tables creates spurious columns Steps to Reproduce: 1. Create a table (size matters not). A 1x1 will work just as well. 2. Position the cursor/caret in the table after creation. 3. Press Tab twice. Expected Results: It used to be that within table bounds we'd just create additional _rows_, as opposed to _columns_. Actual Results: We now create (on the 2nd Tab press) extra columns with missing cells, capped off by a full cell at the end of the row. (Hard to describe, sorry; see screenshot and/or try to reproduce for yourself.) Some sort of bounds-testing code is awry, here.

Here's the stacktrace leading to the creation of the extra column: #2 0x049f8ff4 in nsTableCellMap::AddColsAtEnd (this=0x224a8d90, aNumCols=1) at /Users/urib/mozilla/layout/tables/nsCellMap.cpp:423 #3 0x049fb160 in nsCellMap::SetDataAt (this=0x2067f270, aMap=@0x224a8d90, aNewCell=@0x2168b220, aMapRowIndex=0, aColIndex=1, aCountZeroSpanAsSpan=0) at /Users/urib/mozilla/layout/tables/nsCellMap.cpp:2382 #4 0x049fbad4 in nsCellMap::GetDataAt (this=0x2067f270, aMap=@0x224a8d90, aMapRowIndex=0, aColIndex=1, aUpdateZeroSpan=1) at /Users/urib/mozilla/layout/tables/nsCellMap.cpp:2359 #5 0x049fca20 in nsCellMap::GetCellInfoAt (this=0x2067f270, aMap=@0x224a8d90, aRowX=0, aColX=1, aOriginates=0xbfffd4f8, aColSpan=0xbfffd4fc) at /Users/urib/mozilla/layout/tables/nsCellMap.cpp:2420 #6 0x049fcbd4 in nsTableCellMap::GetCellInfoAt (this=0x224a8d90, aRowIndex=0, aColIndex=1, aOriginates=0xbfffd4f8, aColSpan=0xbfffd4fc) at /Users/urib/mozilla/layout/tables/nsCellMap.cpp:762 #7 0x04a25350 in nsTableFrame::GetCellDataAt (this=0x24e740c, aRowIndex=0, aColIndex=1, aCell=@0xbfffd5f8, aStartRowIndex=@0xbfffd6d0, aStartColIndex=@0xbfffd6d4, aRowSpan=@0xbfffd6d8, aColSpan=@0xbfffd6dc, aActualRowSpan=@0xbfffd6e0, aActualColSpan=@0xbfffd6e4, aIsSelected=@0xbfffd6e8) at /Users/urib/mozilla/layout/tables/nsTableFrame.cpp:4553 #8 0x04a2ccc0 in nsTableOuterFrame::GetCellDataAt (this=0x24e730c, aRowIndex=0, aColIndex=1, aCell=@0xbfffd5f8, aStartRowIndex=@0xbfffd6d0, aStartColIndex=@0xbfffd6d4, aRowSpan=@0xbfffd6d8, aColSpan=@0xbfffd6dc, aActualRowSpan=@0xbfffd6e0, aActualColSpan=@0xbfffd6e4, aIsSelected=@0xbfffd6e8) at /Users/urib/mozilla/layout/tables/nsTableOuterFrame.cpp:2132 #9 0x0335b2ec in nsHTMLEditor::GetCellDataAt (this=0x22cba00, aTable=0x222a169c, aRowIndex=0, aColIndex=1, aCell=0xbfffd6c4, aStartRowIndex=0xbfffd6d0, aStartColIndex=0xbfffd6d4, aRowSpan=0xbfffd6d8, aColSpan=0xbfffd6dc, aActualRowSpan=0xbfffd6e0, aActualColSpan=0xbfffd6e4, aIsSelected=0xbfffd6e8) at /Users/urib/mozilla/editor/libeditor/html/nsTableEditor.cpp:2862 #10 0x03359b60 in nsHTMLEditor::InsertTableRow (this=0x22cba00, aNumber=1, aAfter=1) at /Users/urib/mozilla/editor/libeditor/html/nsTableEditor.cpp:726 The problem seems to be at frame #4, i.e, the call from nsCellMap::GetDataAt() to nsCellMap::SetDataAt(). This call was added in bug 271789.

nsHTMLEditor::GetCellDataAt (this=0x22cba00, aTable=0x222a169c, aRowIndex=0, aColIndex=1, aCell=0xbfffd6c4, aStartRowIndex=0xbfffd6d0, aStartColIndex=0xbfffd6d4, aRowSpan=0xbfffd6d8, aColSpan=0xbfffd6dc, aActualRowSpan=0xbfffd6e0, aActualColSpan=0xbfffd6e4, aIsSelected=0xbfffd6e8) isnt this what the code is asking for aColIndex=1 is the second column.

So nsHTMLEditor::InsertTableRow does this weird loop over columns (see the loop at 684 while ( NS_OK == GetCellDataAt(table, startRowIndex, colIndex, ). I guess it expects to get back an error when there are no more columns... It expects to end up with a NS_TABLELAYOUT_CELL_NOT_FOUND error when calling GetCellDataAt (off of the nsITableLayout interface) off the end of the table. So it sounds like nsTableFrame::GetCellDataAt should do whatever it needs to to not actually modify the cellmap? Or something?

Does this fix the issue?

Seems to fix the issue, with the patch i get the same results as noted under "Expected Results".

this is trunk only

fix checked in

.

Verified FIXED using build 2006-03-04-08 in SeaMonkey trunk on Windows XP.