| Summary: | RenderBlocks with negative width | ||
|---|---|---|---|
| Product: | WebKit | Reporter: | James Robinson <jamesr> |
| Component: | Layout and Rendering | Assignee: | Nobody <webkit-unassigned> |
| Status: | RESOLVED CONFIGURATION CHANGED | ||
| Severity: | Normal | CC: | aestes, ahmad.saleem792, hyatt, mihaip, simon.fraser, zalan |
| Priority: | P2 | ||
| Version: | 528+ (Nightly build) | ||
| Hardware: | PC | ||
| OS: | OS X 10.5 | ||
| URL: | http://nytimes.com/chrome | ||
|
Description
James Robinson
2011-03-10 17:07:15 PST
Repro: <!DOCTYPE html> <div id="d" style="margin-left: 100%; position: absolute; left: 20px; right: 160px;"></div> d.clientWidth is -180 in WebKit and 0 in Firefox 3.6, Firefox 4 beta, Opera 10.62, and IE8. The -180 value seems to come from here: http://trac.webkit.org/browser/trunk/Source/WebCore/rendering/RenderBox.cpp#L2422 This doesn't appear to be a recent regression. After chatting with Tab it seems the issue is that when calculating the logical width we need to handle the case where the width goes negative by dropping a constraint and re-solving (dropping into the !logicalLeftIsAuto && !logicalWidthIsAuto && !logicalRightIsAuto case would seem to do the trick here). It looks like what Gecko 2.0 does is ignore the specified value for 'right' and re-solving - the computed values for left/right/width are 20px/-20px/0px, respectively in this test case. The same issue exists for padding/borders. Test Case (based on Comment 01): https://jsfiddle.net/w17kymqg/2/ ^ Though tweaked to output clientWidth. *** Safari 16.5 *** clientHeight: 0px clientWidth: 0px *** Chrome Canary 115 & Firefox Nightly 115 *** clientHeight: 0px clientWidth: 0px ________ We don't get -180, which this bug was about. So I am marking this as "RESOLVED CONFIGURATION CHANGED". |