Bug 10633 - incomplete repaint after programatically floating a radio button form control
Summary: incomplete repaint after programatically floating a radio button form control
Status: RESOLVED FIXED
Alias: None
Product: WebKit
Classification: Unclassified
Component: Layout and Rendering (show other bugs)
Version: 420+
Hardware: Mac OS X 10.4
: P2 Normal
Assignee: Nobody
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2006-08-29 14:26 PDT by Geoffrey Garen
Modified: 2007-02-20 00:22 PST (History)
3 users (show)

See Also:


Attachments
reduction (357 bytes, text/html)
2006-08-29 14:26 PDT, Geoffrey Garen
no flags Details
picture (8.35 KB, image/png)
2006-08-29 14:27 PDT, Geoffrey Garen
no flags Details
Slightly simplified reduction (297 bytes, text/html)
2006-08-31 11:40 PDT, mitz
no flags Details
Another test case for the layout issue (609 bytes, text/html)
2006-12-30 12:26 PST, mitz
no flags Details
Test for strict mode (1.80 KB, text/html)
2006-12-30 12:52 PST, mitz
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Geoffrey Garen 2006-08-29 14:26:06 PDT
See attached test case and picture.
Comment 1 Geoffrey Garen 2006-08-29 14:26:55 PDT
Created attachment 10304 [details]
reduction
Comment 2 Geoffrey Garen 2006-08-29 14:27:18 PDT
Created attachment 10305 [details]
picture
Comment 3 mitz 2006-08-29 14:38:27 PDT
The reduction fails to repaint in shipping WebKit (418.8) as well.
Comment 4 mitz 2006-08-31 11:40:39 PDT
Created attachment 10336 [details]
Slightly simplified reduction

Got rid of the form, button and iframe and a few unnecessary css properties.

This is actually first and foremost an incomplete relayout bug: after you click the button, you get incomplete repainting. You can force repaint and see that the black rectangle has become narrower. But if you force relayout at that point (e.g. by resizing the window), you'll see that it grows back to its original width. I believe that the repainting issue is an artifact of the layout problem.
Comment 5 mitz 2006-08-31 12:56:58 PDT
The problem here is a replaced object with percent width. To compute the width, you need to know the object's y coordinate (then you compute the available width at that y coordindate), but currently layoutInlineChildren tells replaced inline children to layout (and decide their width) before they know their final y position, using their last y position (or 0 if it's the first time).

Perhaps you can defer layout of replaced children until findNextLineBreak reaches them, and then at least you can guess the replaced object's y position consistently (you may need to guess and layout again if it doesn't fit and ends up moving down to clear floats or wrapping to the next line).
Comment 6 mitz 2006-12-30 12:26:16 PST
Created attachment 12125 [details]
Another test case for the layout issue

Opera and Firefox (when replacing the inline-block div with an img) compute the percentage out of the width of the blue div, ignoring the float.
Comment 7 mitz 2006-12-30 12:52:35 PST
Created attachment 12126 [details]
Test for strict mode

The problem is only in present in quirks mode (although I don't understand the behavior in the 4th case in this file). Here is a comment from RenderObject::usesLineWidth() explaining the quirk:
    // 1. All auto-width objects that avoid floats should always use lineWidth
    // 2. For objects with a specified width, we match WinIE's behavior:
    // (a) tables use contentWidth
    // (b) <hr>s use lineWidth
    // (c) all other objects use lineWidth in quirks mode and contentWidth in strict mode.
Comment 8 mitz 2007-02-20 00:22:23 PST
Quirk removed by Hyatt in <http://trac.webkit.org/projects/webkit/changeset/19717>.