Bug 101803

Created attachment 173687 [details] Patch

Does this have a perf impact?

Comment on attachment 173687 [details] Patch Attachment 173687 [details] did not pass efl-ews (efl): Output: http://queues.webkit.org/results/14806693

Comment on attachment 173687 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=173687&action=review r- > Source/WebCore/rendering/RenderBlockLineLayout.cpp:142 > - return logicalHeight; > + return block->lineHeight(true, block->isHorizontalWritingMode() ? HorizontalLine : VerticalLine, PositionOfInteriorLineBoxes); It's a little weird that you ignore line-box-contain values that might have indicated the block's line-height should be ignored. I don't have a really good solution if that is the case, however, since I'm not sure what we want to do in that situation. We can either leave this alone with a FIXME, or we can decide that if the block is excluded we return 0 instead. I'm leaning towards returning 0. > Source/WebCore/rendering/RenderBlockLineLayout.cpp:145 > if (lineBox->firstChild() && lineBox->firstChild()->renderer() && lineBox->firstChild()->renderer()->isRenderBlock()) > - logicalHeight = toRenderBlock(lineBox->firstChild()->renderer())->logicalHeight(); > - else > - logicalHeight = lineBox->height(); > - return logicalHeight; > + return toRenderBlock(lineBox->firstChild()->renderer())->logicalHeight(); This just looks all wrong to me. I don't understand any of it. Neither the original code nor the new code look right to me.

I think you should just use the block line height and cut out the inline block checking for now. Also, you need to handle line-box-contain values that exclude block (just use 0 in that case), and I think if you're not in strict mode, you should just use 0 too, since otherwise you'll mess up the quirks mode cases where images have their descent removed.

Created attachment 173709 [details] A test case with a big inline box

Created attachment 175025 [details] Patch

Comment on attachment 175025 [details] Patch Attachment 175025 [details] did not pass chromium-ews (chromium-xvfb): Output: http://queues.webkit.org/results/14894360 New failing tests: css2.1/20110323/floats-wrap-top-below-inline-001r.htm

Comment on attachment 175025 [details] Patch Attachment 175025 [details] did not pass mac-ews (mac): Output: http://queues.webkit.org/results/14907496 New failing tests: fast/block/float/floats-offset-inline-block-strict-lineheight.html css2.1/20110323/floats-wrap-top-below-inline-001r.htm fast/block/float/floats-offset-image-strict-lineheight.html fast/block/float/floats-offset-image-strict.html

Created attachment 175163 [details] Patch

Comment on attachment 175163 [details] Patch Attachment 175163 [details] did not pass mac-ews (mac): Output: http://queues.webkit.org/results/14901536 New failing tests: fast/block/float/floats-offset-inline-block-strict-lineheight.html fast/block/float/floats-offset-image-strict-lineheight.html fast/block/float/floats-offset-image-strict.html

Created attachment 175597 [details] Patch

Comment on attachment 175597 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=175597&action=review r- > Source/WebCore/rendering/RenderBlockLineLayout.cpp:140 > + if (block->document()->inQuirksMode() && replacedHeight) > + return replacedHeight; I think this replaced stuff needs work. I'd prefer we just get the simplest fix in first. For now, let's just change this to: if (!block->document()->inNoQuirksMode()) return 0; Note that the descent clipping for replaced elements happens even in LimitedQuirksMode, so you need to specifically target NoQuirksMode only. > Source/WebCore/rendering/RenderBlockLineLayout.cpp:950 > + if (!previousObject && r->m_object->isReplaced()) { > + RenderBox* renderBox = toRenderBox(r->m_object); > + LayoutUnit lineLogicalHeight = logicalHeightForLine(this, firstLine, renderBox->logicalHeight()); > + logicalLeft = pixelSnappedLogicalLeftOffsetForLine(logicalHeight(), firstLine, lineLogicalHeight); > + logicalRight = pixelSnappedLogicalRightOffsetForLine(logicalHeight(), firstLine, lineLogicalHeight); > +#if ENABLE(CSS_EXCLUSIONS) > + if (exclusionShapeInsideInfo && exclusionShapeInsideInfo->hasSegments()) { > + logicalLeft = max<float>(roundToInt(exclusionShapeInsideInfo->segments()[0].logicalLeft), logicalLeft); > + logicalRight = min<float>(floorToInt(exclusionShapeInsideInfo->segments()[0].logicalRight), logicalRight); > + } > +#endif > + availableLogicalWidth = logicalRight - logicalLeft; > + } Just cut this for now. > Source/WebCore/rendering/RenderBlockLineLayout.cpp:2500 > + if (atStart) > + width.updateAvailableWidth(replacedBox->logicalHeight()); Just drop this for now. Let's figure out the replaced element handling in a separate patch.

Created attachment 176044 [details] Patch

Comment on attachment 176044 [details] Patch Attachment 176044 [details] did not pass mac-ews (mac): Output: http://queues.webkit.org/results/14980895 New failing tests: css1/formatting_model/floating_elements.html fast/block/float/010.html fast/block/float/independent-align-positioning.html

Comment on attachment 176044 [details] Patch Attachment 176044 [details] did not pass chromium-ews (chromium-xvfb): Output: http://queues.webkit.org/results/14985841 New failing tests: css1/formatting_model/floating_elements.html fast/text/atsui-small-caps-punctuation-size.html

Created attachment 176809 [details] Patch

Comment on attachment 176809 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=176809&action=review Just one question. > Source/WebCore/rendering/RenderBlockLineLayout.cpp:140 > + if (block->document()->inQuirksMode() && replacedHeight) > + return replacedHeight; Why only in quirks mode? Lines still grow to accommodate replaced elements in all modes. I'm not really understanding this part. Note the difference between NoQuirksMode and the other two modes is that in NoQuirksMode, baseline-aligned images still have descent. Even if your heuristic isn't good enough to account for this descent, the replacedHeight is still relevant in all modes.

(In reply to comment #19) > (From update of attachment 176809 [details]) > View in context: https://bugs.webkit.org/attachment.cgi?id=176809&action=review > > Just one question. > > > Source/WebCore/rendering/RenderBlockLineLayout.cpp:140 > > + if (block->document()->inQuirksMode() && replacedHeight) > > + return replacedHeight; > > Why only in quirks mode? Lines still grow to accommodate replaced elements in all modes. I'm not really understanding this part. > > Note the difference between NoQuirksMode and the other two modes is that in NoQuirksMode, baseline-aligned images still have descent. Even if your heuristic isn't good enough to account for this descent, the replacedHeight is still relevant in all modes. That's right - in the other modes I can just take the maximum of the line-height or replacedHeight. It's only in quirks mode that the descent is ignored completely like this - and I've just realized you asked me to change this to !block->document()->inNoQuirksMode()

Created attachment 178035 [details] Patch

Created attachment 178347 [details] Patch

Comment on attachment 178347 [details] Patch Attachment 178347 [details] did not pass mac-ews (mac): Output: http://queues.webkit.org/results/15189659

Created attachment 178348 [details] Patch

Comment on attachment 178348 [details] Patch Attachment 178348 [details] did not pass mac-ews (mac): Output: http://queues.webkit.org/results/15210495

Created attachment 178370 [details] Patch

Comment on attachment 178370 [details] Patch r=me

Comment on attachment 178370 [details] Patch Clearing flags on attachment: 178370 Committed r137331: <http://trac.webkit.org/changeset/137331>

All reviewed patches have been landed. Closing bug.

This patch broke the layout of http://www.usspotemkin.com

(In reply to comment #30) > This patch broke the layout of http://www.usspotemkin.com Filed https://bugs.webkit.org/show_bug.cgi?id=110910 to track this.