User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:5.0.1) Gecko/20100101 Firefox/5.0.1
Build ID: 20110707182747
Steps to reproduce:
Create a relative positioned element with defined width/height that contains an absolute positioned element with a larger defined width/height. Check the scrollWidth/Height of the relative positioned element.
The scrollWidth/Height don't account for the absolutely positioned element unless overflow: scroll is set.
The scrollWidth/Height should account for the absolutely positioned element.
WebKit seems to do what the draft says (or vice versa). Presto agrees with us. What does Trident do?
As in, does the draft say what it should?
I spoke with Divya as I was filing this bug and she filed a bug with Opera. As for Trident, IE 7 and lower have the same behavior as Firefox; as of IE 8 it has the same behavior as WebKit.
I personally don't have a preference for what the draft should say. I actually expected the behavior that Firefox has, but others seem to expect the WebKit behavior and the spec seems to describe it that way. However, I didn't notice anything in the spec that said the positioning should affect the scroll dimensions, and changing the position to static causes the "clipped" size in all browsers.
(In reply to Boris Zbarsky (:bz) from comment #1)
> What does Trident do?
Quirks mode: as Presto/Gecko Standards mode: as Webkit/spec
> As in, does the draft say what it should?
"4. Return the computed value of the 'padding-left' property, plus the computed value of the 'padding-right', plus the content width of the element."
where "content width" is defined as:
"The term content refers to the dimensions of the element's content area, including overflown content."
It doesn't make sense to me (adding padding around overflowing children?)
I guess it's trying to say that we should use the overflow rect,
but calling that "content width" is unfortunate - it's very easy to
confuse with the common CSS "content box width".
Heh, [css3-box] even uses the same fragment ID for its definition.
s/"content box width"/"content area width"
See thread starting http://lists.w3.org/Archives/Public/www-style/2011Aug/0621.html
Created attachment 714089 [details]
Attached is a test case. In Firefox (18.0.2, 19.0b, 20.0a2 (2013-02-14)) and Opera 12.14, the scrollWidth and scrollHeight are the dimensions of the . In IE 10, IE 8, Safari 6.0.2, and Chrome 24.0.1312.57 the scrollWidth is 75 and the scrollHeight is 125.
If you edit the test case to change the `position' of #innerBox to `relative', Firefox gives an even stranger result of 25x44px on my machine, which seems to be the dimensions of the content as if #innerBox did not have `top' and `left' properties applied.
If I add `overflow:hidden' to #theBox, then Firefox switches to agreeing with IE and WebKit. So, this is only a problem if `overflow' is `visible'.
There was a recent change made to the scrollWidth and scrollHeight calculations for the overflow:visible case (see Bug 833542). Using the test case in a build that I just made (Firefox 21.0a1 (2013-02-14)), this issue appears to have been fixed. Perhaps the patch for Bug 833542 also fixed this bug?
I used mozregression and found:
Last bad nightly (contains Bug 678678): 2013-01-29
First good nightly (fixed): 2013-01-30
Robert's patch for Bug 833542 (included in d3a5e1de98b0) is in the range, and it looks like the 833542 patch was the only one related to scrollWidth/scrollHeight.
So, it looks like the patch for Bug 833542 also fixed this bug.
Daniel, thanks for double-checking that!
Created attachment 742857 [details] [diff] [review]
This is a patch which turns the previously supplied test case into a regression test.