Last Comment Bug 678678 - scrollWidth/Height doesn't account for absolutely positioned overflown content
: scrollWidth/Height doesn't account for absolutely positioned overflown content
: testcase
Product: Core
Classification: Components
Component: DOM: CSS Object Model (show other bugs)
: Trunk
: All All
: -- normal with 1 vote (vote)
: ---
Assigned To: Nobody; OK to take it and work on it
: Andrew Overholt [:overholt]
Depends on: 833542
  Show dependency treegraph
Reported: 2011-08-12 18:09 PDT by Scott González
Modified: 2014-01-09 06:52 PST (History)
5 users (show)
bzbarsky: in‑testsuite?
See Also:
Crash Signature:
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---

Test case (801 bytes, text/plain)
2013-02-14 14:06 PST, Daniel Trebbien
no flags Details
add test (3.50 KB, patch)
2013-04-28 15:59 PDT, Daniel Trebbien
no flags Details | Diff | Splinter Review

Description Scott González 2011-08-12 18:09:59 PDT
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.
Comment 1 Boris Zbarsky [:bz] (still a bit busy) 2011-08-14 20:26:02 PDT
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 2011-08-15 05:06:44 PDT
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 (:mats) 2011-08-15 16:13:07 PDT
(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.
Comment 4 Mats Palmgren (:mats) 2011-08-15 19:22:08 PDT
s/"content box width"/"content area width"
Comment 5 Boris Zbarsky [:bz] (still a bit busy) 2011-08-24 14:17:10 PDT
See thread starting
Comment 6 Daniel Trebbien 2013-02-14 14:06:08 PST
Created attachment 714089 [details]
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 2013-02-14 15:22:22 PST
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 2013-04-12 08:29:30 PDT
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.
Comment 9 Boris Zbarsky [:bz] (still a bit busy) 2013-04-12 09:01:10 PDT
Daniel, thanks for double-checking that!
Comment 10 Daniel Trebbien 2013-04-28 15:59:37 PDT
Created attachment 742857 [details] [diff] [review]
add test

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

Note You need to log in before you can comment on or make changes to this bug.