Bug 76451 – Ignoring padding-right of inline elements in containers with undefined width

• Component: New Bugs
• Status: RESOLVED FIXED

[Alex]

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.

[Arpita Bahuguna]

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.

[Robert Hogan]

Created attachment 204846 [details]
Patch

[Robert Hogan]

Created attachment 204924 [details]
Patch

[Dave Hyatt]

Comment on attachment 204924 [details]
Patch

r=me

[WebKit Commit Bot]

Comment on attachment 204924 [details]
Patch

Clearing flags on attachment: 204924

Committed r151855: <http://trac.webkit.org/changeset/151855>

[WebKit Commit Bot]

All reviewed patches have been landed.  Closing bug.