Summary: | Assertion failure in RenderObject::drawLineForBoxSide | ||||||||
---|---|---|---|---|---|---|---|---|---|
Product: | WebKit | Reporter: | Matt Falkenhagen <falken> | ||||||
Component: | Layout and Rendering | Assignee: | Nobody <webkit-unassigned> | ||||||
Status: | RESOLVED CONFIGURATION CHANGED | ||||||||
Severity: | Normal | CC: | ahmad.saleem792, bdakin, jchaffraix, mitz, simon.fraser | ||||||
Priority: | P2 | ||||||||
Version: | 528+ (Nightly build) | ||||||||
Hardware: | Unspecified | ||||||||
OS: | Unspecified | ||||||||
Attachments: |
|
Description
Matt Falkenhagen
2012-10-09 23:54:05 PDT
It looks like it's not a recent regression. A build of June 1, 2012 Chromium also fails the assertion. Created attachment 172751 [details]
more minimal testcase
The problem here is the render box gets a computed width of -1 during layout. Then the rect computed in RenderBox::paintBoxDecorations by calling RenderBox::borderBoxRectFromRegion also gets a width of -1. Ultimately the assert is tripped when x1=0 and x2=-1 is passed to RenderObject::drawLineForBoxSide. The computed width comes from the "// RULE 5 (Solve for width)" section in RenderBox::computePositionedLogicalWidthUsing. Since left is 1 and right is 0, the solved for width is -1. In more detail: const LayoutUnit availableSpace = containerLogicalWidth - (marginLogicalLeftValue + marginLogicalRightValue + bordersPlusPadding); Here everything is 0 except borderPlusPadding=6, so availableSpace is -6. Then we get to RULE 5, where: logicalLeftValue = valueForLength(logicalLeft, containerLogicalWidth, renderView); computedValues.m_extent = availableSpace - (logicalLeftValue + valueForLength(logicalRight, containerLogicalWidth, renderView)); Here logicalLeft=1 and logicalRight=0, so m_extent is -7. Later in computePositionedLogicalWidth: computedValues.m_extent += bordersPlusPadding; So m_extent is -1, which becomes the logical width of the renderer. I guess there must be a reason that negative widths aren't clamped to zero during layout. If so, the question is how to avoid painting a border with negative dimensions. We could maybe do an early return in RenderBox::paintBoxDecorations when the paintRect has negative dimensions. Or since drawLineForBoxSide already has a check: if (!thickness || !length) We could extend it to check for negatives. But oddly code in that function seems to expect negative dimensions as valid (there is a thickness > 0 check later and only for the SOLID case is there an assert for non-negative). Or maybe we want to paint the border after all and can just remove the assert. In this test case, Firefox seems to paint a little 6 pixel block as the border. I am unable to reproduce 'Assert Failure' on Debug Build (275804@main) using attached test case. Marking this as 'RESOLVED CONFIGURATION CHANGED'. |