[Webkit-unassigned] [Bug 40775] New: Table Cell Layering

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=40775

           Summary: Table Cell Layering
           Product: WebKit
           Version: 528+ (Nightly build)
          Platform: PC
        OS/Version: Mac OS X 10.6
            Status: UNCONFIRMED
          Severity: Normal
          Priority: P2
         Component: Layout and Rendering
        AssignedTo: webkit-unassigned at lists.webkit.org
        ReportedBy: fsamuel at chromium.org
                CC: hyatt at apple.com, rjkroege at chromium.org


Layering of table cells is not implemented correctly in WebKit which means there will occasionally be rendering issues when cells overlap in tables. Currently the RenderTableSection object does not keep track of more than one cell for any given grid slot in a table. Through the use of colspan and rowspan attribute, multiple cells may overlap in a single cell slot. 

<TABLE border="1">
<TR><TD>1 <TD>2 <TD>3
<TR><TD>4 <TD rowspan="2">5 <TD>6
<TR><TD colspan="2">7 <TD>9
</TABLE>

The issue of layering is most evident when you assign background colors to overlapping cells. In the patch, I've included two tests that demonstrate the inconsistent/incorrect behavior of Webkit relative to other browsers. 

Technically (according to the spec, http://www.w3.org/TR/html401/struct/tables.html) cell overlap is an 'error' but it is supported on all the major browsers and the behavior is consistent on all the major browsers (with the exception of a few subtle inconsistencies in webkit). WebKit starts messing up painting if dirty paint rects are small. 

The patch here fixes the issue by keeping track of all cells that lie on each grid slot of the table. Cells are assigned a layer number on layout (in RenderTableSection::addCell). A cell that does not overlap with any other cells is assigned a layer number 0. Otherwise, a cell's layer is defined to be 1 + the greatest overlapped cell layer.

On paint, the RenderTableSection object iterates over all the cells that lie on the dirty grid slots. It paints all layer 0 cells directly as they do not overlap with any other cells. It then takes all non-layer 0 cells in the dirty rect, sorts them by layer number, and then paints the layers from 1 onward. In the simplest (and most common) case where there is no overlap, the performance impact on table rendering should be negligible.

Subtle hit testing bugs also exist when doing cell layering as well. These are not fixed in this first patch but will be fixed in a subsequent patch

This is the first of several patches that will be coming to tweak table layout and rendering for performance and compatibility (to better match the behavior of other browsers in edge cases). 

I've split up my work into several patches to smooth out the review process. In the next few patches, I will be doing the following :

1. Issue hit testing on a grid slot in the order of cells layered on that slot (i.e. the topmost cells receives the hit test first and then the one underneath it and so on).
2. Use binary search on both hit testing and painting of dirty rects to identify which cells need to be repainted (current patch uses a linear scan). This should provide a nice perf boost when updating small parts of a very large table. Use counting sort (instead of qsort) when painting dirty rects.
3. Update table layout to better match IE, firefox, and opera in edge cases (e.g. how other browsers treat empty cells and rows that have column counts that don't match). 
4. Possibly opacity/translucency of overlapping cell backgrounds? (This might allow for neat effects although, again, outside the spec).

-- 
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.