Those 2 booleans are duplicating the information stored in prevCell / nextCell. As we have to compute the previous / next cell in the common case, it's probably better to stick with them. Patch forthcoming.
Created attachment 164580 [details] Proposed change: remove isEndColumn / isStartColumn and clean up the code.
Comment on attachment 164580 [details] Proposed change: remove isEndColumn / isStartColumn and clean up the code. The cr-linux EWS is sick but I confirm that it regresses fast/repaint/table-collapsed-border.html. Holding the patch until I can investigate.
Comment on attachment 164580 [details] Proposed change: remove isEndColumn / isStartColumn and clean up the code. Attachment 164580 [details] did not pass chromium-ews (chromium-xvfb): Output: http://queues.webkit.org/results/13896379 New failing tests: fast/repaint/table-collapsed-border.html
> The cr-linux EWS is sick but I confirm that it regresses fast/repaint/table-collapsed-border.html. Holding the patch until I can investigate. OK, one of the assumption I made is wrong: isEndColumn == !cellAfter is just untrue because the table doesn't have to be regular in structure. <table> <tr> <td></td> <td></td> </tr> <tr> <td></td> </tr> </table> The previous table is valid but we would wrongly computes the second row's cell's end border.
We need isEndColumn for the previous reason but isStartColumn is fully embedded into cellBefore as we add the cells in order. Renaming the bug.
Created attachment 164754 [details] Change v2. Keep isEndColumn and explain why it's needed.
Created attachment 164822 [details] Patch for landing.
Comment on attachment 164822 [details] Patch for landing. Clearing flags on attachment: 164822 Committed r129136: <http://trac.webkit.org/changeset/129136>
All reviewed patches have been landed. Closing bug.