678678 - scrollWidth/Height doesn't account for absolutely positioned overflown content

Status: RESOLVED FIXED

(Core :: DOM: CSS Object Model, defect)

Description

[Scott González]

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.


Actual results:

The scrollWidth/Height don't account for the absolutely positioned element unless overflow: scroll is set.


Expected results:

The scrollWidth/Height should account for the absolutely positioned element.

http://dev.w3.org/csswg/cssom-view/#dom-element-scrollwidth

Comment 1

[Boris Zbarsky [:bzbarsky]]

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?

Comment 2

[Scott González]

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.

Comment 3

[Mats Palmgren (inactive)]

(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."
http://dev.w3.org/csswg/cssom-view/#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".
http://www.w3.org/TR/css3-box/#various

Heh, [css3-box] even uses the same fragment ID for its definition.
http://www.w3.org/TR/css3-box/#content

Comment 4

[Mats Palmgren (inactive)]

s/"content box width"/"content area width"

Comment 5

[Boris Zbarsky [:bzbarsky]]

See thread starting http://lists.w3.org/Archives/Public/www-style/2011Aug/0621.html

Comment 6

[Daniel Trebbien]

Attachment: Test case

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.

Comment 7

[Daniel Trebbien]

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?

Comment 8

[Daniel Trebbien]

I used mozregression and found:

Last bad nightly (contains Bug 678678): 2013-01-29
First good nightly (fixed): 2013-01-30

Pushlog:
http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=0c45e6378f1f&tochange=677e87c11252

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.

Comment 9

[Boris Zbarsky [:bzbarsky]]

Daniel, thanks for double-checking that!

Comment 10

[Daniel Trebbien]

Attachment: add test

This is a patch which turns the previously supplied test case into a regression test.