LayoutTests:
authorantti <antti@268f45cc-cd09-0410-ab3c-d52691b4dbfc>
Thu, 16 Aug 2007 16:13:28 +0000 (16:13 +0000)
committerantti <antti@268f45cc-cd09-0410-ab3c-d52691b4dbfc>
Thu, 16 Aug 2007 16:13:28 +0000 (16:13 +0000)
commitf14bdad13565f06e020268ee5d7cc4495e5c678e
tree50b6dbd3f48397a421d3f03484795ee8c5255efb
parent8a5b288e5999859aacc58258f224dba5b0683554
LayoutTests:

        Reviewed by Maciej.

        Test for <rdar://problem/5388936>
        Crash while setting display:none for a table cell with selection

        * fast/table/destroy-cell-with-selection-crash-expected.txt: Added.
        * fast/table/destroy-cell-with-selection-crash.html: Added.

WebCore:

        Reviewed by Maciej.

        Fix <rdar://problem/5388936>
        Crash while setting display:none for a table cell with selection

        Super class destroy() could (through some selection code in removeChild()) trigger section recalc
        in middle of RenderTableCell::destroy(), cleaning section dirty bit. This would later crash in
        layout since cell grid would still have refence to the dead cell.

        Ensure table sections are dirty when leaving destroy method.

        I can't figure out tests for row and section changes but they look like
        they could crash in similar way as cell.

        * rendering/RenderTableCell.cpp:
        (WebCore::RenderTableCell::destroy):
        * rendering/RenderTableRow.cpp:
        (WebCore::RenderTableRow::destroy):
        * rendering/RenderTableSection.cpp:
        (WebCore::RenderTableSection::destroy):

git-svn-id: https://svn.webkit.org/repository/webkit/trunk@25106 268f45cc-cd09-0410-ab3c-d52691b4dbfc
LayoutTests/ChangeLog
LayoutTests/fast/table/destroy-cell-with-selection-crash-expected.txt [new file with mode: 0644]
LayoutTests/fast/table/destroy-cell-with-selection-crash.html [new file with mode: 0644]
WebCore/ChangeLog
WebCore/rendering/RenderTableCell.cpp
WebCore/rendering/RenderTableRow.cpp
WebCore/rendering/RenderTableSection.cpp