56153 2011-03-10 17:07:15 -0800 RenderBlocks with negative width 2023-05-20 09:56:29 -0700 1 1 1 Unclassified WebKit Layout and Rendering 528+ (Nightly build) PC OS X 10.5 RESOLVED CONFIGURATION CHANGED http://nytimes.com/chrome P2 Normal --- 1 jamesr webkit-unassigned aestes ahmad.saleem792 hyatt mihaip simon.fraser zalan oldest_to_newest 365682 0 jamesr 2011-03-10 17:07:15 -0800 When loading the given URL a set of RenderBlocks have negative widths, which causes a number of problems. I'm currently bisecting to figure out when this started happening as it seems to be a fairly recent regression. 366483 1 jamesr 2011-03-11 19:23:33 -0800 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. 367162 2 jamesr 2011-03-14 13:14:31 -0700 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. 1956737 3 ahmad.saleem792 2023-05-20 09:56:29 -0700 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".