Bug 76451 - Ignoring padding-right of inline elements in containers with undefined width
Summary: Ignoring padding-right of inline elements in containers with undefined width
Alias: None
Product: WebKit
Classification: Unclassified
Component: New Bugs (show other bugs)
Version: 528+ (Nightly build)
Hardware: PC Windows 7
: P2 Major
Assignee: Robert Hogan
URL: http://optio.com.ru/temp/webkit/webki...
Depends on:
Reported: 2012-01-17 06:57 PST by Alex
Modified: 2013-06-21 14:04 PDT (History)
7 users (show)

See Also:

Patch (7.34 KB, patch)
2013-06-17 12:04 PDT, Robert Hogan
no flags Details | Formatted Diff | Diff
Patch (8.69 KB, patch)
2013-06-18 10:56 PDT, Robert Hogan
no flags Details | Formatted Diff | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Alex 2012-01-17 06:57:44 PST
Bug demo: http://optio.com.ru/temp/webkit/webkit_bug.html

"span#inside" is inserted into "span#outer" which has padding-right, so its red background should be visible.
But in WebKit padding-right is ignored! 

Adding any width to container "div#cont" or adding padding-left to "span#outer" will "fix" bug.
Comment 1 Arpita Bahuguna 2012-07-17 07:33:36 PDT
The problem is not that WebKit doesn't draw the right padding but rather that it takes into account the space between the nested inline span tags i.e. between the inner </span> and the outer </span> in the test page.
These space characters are treated as a valid text object and thus while rendering, we consider the width of one space character (since we collapse whitespace) which at the time of calculating the positioned container block's width is ignored.
In computeInlinePreferredLogicalWidths(), the width of the text is computed as 120 to which we add the 20px of padding. Thus our containing block has a width of 140px. But for the spaces between the nested inline end tags, we consider 4px width (for one space) which too is added to this 140px and we now get a width of 144px.
At the end of the function we remove this 4px (width of one space character) from the final width of 144px (since we collapse whitespace) and thus get 140px.
So ultimately we assign a width of 140px to our positioned containing block.

Now, when we are laying out the objects RenderBlock::layoutRunsAndFloatsInRange() -> which calls on the RenderBlock::lineBreaker::nextLineBreak() for calculating the end position of the line; we consider the 4px of the space character (and are not ignoring it as was done while computing the width of the containing block) because of which our length (144px) is not able to fit in the given width (140px) and so our end position is calculated incorrectly (i.e. up to the end of the line) which leaves no space for the right padding.

In the case when no position is specified for our containing block, the full width of the view is considered (instead of calculating the specific value) and since 144px can fit within that, there is no discrepancy in the display.
Comment 2 Robert Hogan 2013-06-17 12:04:34 PDT
Created attachment 204846 [details]
Comment 3 Robert Hogan 2013-06-18 10:56:42 PDT
Created attachment 204924 [details]
Comment 4 Dave Hyatt 2013-06-20 14:50:51 PDT
Comment on attachment 204924 [details]

Comment 5 WebKit Commit Bot 2013-06-21 14:04:48 PDT
Comment on attachment 204924 [details]

Clearing flags on attachment: 204924

Committed r151855: <http://trac.webkit.org/changeset/151855>
Comment 6 WebKit Commit Bot 2013-06-21 14:04:52 PDT
All reviewed patches have been landed.  Closing bug.