[webkit-reviews] review denied: [Bug 12123] REGRESSION: Incomplete repaint of floats' overflows : [Attachment 13050] Assign painting of overflowing floats to the parent

[bugzilla-request-daemon at macosforge.org]

Dave Hyatt <hyatt at apple.com> has denied Dave Hyatt <hyatt at apple.com>'s request
for review:
Bug 12123: REGRESSION: Incomplete repaint of floats' overflows
http://bugs.webkit.org/show_bug.cgi?id=12123

Attachment 13050: Assign painting of overflowing floats to the parent
http://bugs.webkit.org/attachment.cgi?id=13050&action=edit

------- Additional Comments from Dave Hyatt <hyatt at apple.com>
This code in RenderTable:

+    if (paintPhase == PaintPhaseFloat)
+	 paintFloats(paintInfo, tx, ty, false);

will (I believe) cause a regression when doing selection dragging, since the
text inside the floats will no longer be painted as part of the selection.

I believe that assigning overflowing floats inside table cells to be painted by
the table will result in potential stacking order regressions if the floats
overlap.

Cells do not paint precisely in document order and yet that's what this float
painting is going to do.

I think now that a different approach is perhaps warranted here.  The issue at
hand seems to be that there are repaint issues with floats because of
horizontal float "overflow".

These sorts of repaint issues have already been solved with normal flow
overflow.  I think a much simpler solution that will avoid forcing tables and
flexible boxes to worry about maintaining floating objects lists would be to
incorporate horizontal spillage from float overflow into m_overflowLeft and
m_overflowWidth.

Vertical float spillage was traditionally not considered overflow simply
because the next block could also contain the float.  However, this is never
the case with horizontal float spillage.  I think you can treat horizontal
float spillage as overflow out of any blocks that the float ends up
intersecting, and you'll end up with a much simpler patch.