| Summary: | Update css3/flexbox/auto-margins.html after r177774 | ||||||
|---|---|---|---|---|---|---|---|
| Product: | WebKit | Reporter: | Myles C. Maxfield <mmaxfield> | ||||
| Component: | New Bugs | Assignee: | Myles C. Maxfield <mmaxfield> | ||||
| Status: | RESOLVED FIXED | ||||||
| Severity: | Normal | CC: | ap, dino, simon.fraser, thorton, zalan | ||||
| Priority: | P2 | ||||||
| Version: | 528+ (Nightly build) | ||||||
| Hardware: | Unspecified | ||||||
| OS: | Unspecified | ||||||
| Bug Depends on: | |||||||
| Bug Blocks: | 139968 | ||||||
| Attachments: |
|
||||||
|
Description
Myles C. Maxfield
2014-12-28 10:32:01 PST
Created attachment 243783 [details]
Patch
Comment on attachment 243783 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=243783&action=review > LayoutTests/ChangeLog:12 > + This is a subpixel problem. Flexbox uses SimpleLineLayout for the entire > + box and therefore does all its math in floating point, while the > + -expected uses the regular renderer hierarchy and therefore fixed-point > + math. This patch updates the test to use Ahem so that the character > + widths divide the same way in both cases. Does that mean that I could see a difference if a page dynamically changed layout between these two techniques? That sounds like a bug! I understand the desire to not make this test sensitive to this bug, but what about fixing the bug? Comment on attachment 243783 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=243783&action=review > LayoutTests/ChangeLog:10 > + This is a subpixel problem. Flexbox uses SimpleLineLayout for the entire > + box and therefore does all its math in floating point, while the > + -expected uses the regular renderer hierarchy and therefore fixed-point Simple line layout snaps content to pixels at painting time the same way as any other InlineBox/RenderBox does. Whether it uses float or LayoutUnit while layouting shouldn't make any difference (other than in some edge cases caused by precession loss -where we might push content to the wrong position at halfway values). I think this is more about table layout vs. rest of the rendering layout, where table still uses integral positioning. Committed r178063: <http://trac.webkit.org/changeset/178063> Zalan says we already have a few bugs about subpixelifying tables, so I'm going to land this. (In reply to comment #5) > Zalan says we already have a few bugs about subpixelifying tables, so I'm > going to land this. bug 132010 |