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

RESOLVED FIXED

Status

()

Core
DOM: CSS Object Model
RESOLVED FIXED
6 years ago
3 years ago

People

(Reporter: Scott González, Unassigned)

Tracking

({testcase})

Trunk
testcase
Points:
---
Bug Flags:
in-testsuite ?

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [cssom-view], URL)

Attachments

(1 attachment, 1 obsolete attachment)

3.50 KB, patch
Details | Diff | Splinter Review
(Reporter)

Description

6 years ago
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
(Reporter)

Updated

6 years ago

Updated

6 years ago
Keywords: testcase

Updated

6 years ago
Status: UNCONFIRMED → NEW
Component: General → DOM: CSS Object Model
Ever confirmed: true
OS: Mac OS X → All
Product: Firefox → Core
QA Contact: general → style-system
Hardware: x86 → All
Whiteboard: [cssom-view]
Version: 5 Branch → Trunk
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?
(Reporter)

Comment 2

6 years ago
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."
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
s/"content box width"/"content area width"
See thread starting http://lists.w3.org/Archives/Public/www-style/2011Aug/0621.html

Comment 6

4 years ago
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

4 years ago
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

4 years ago
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.
Daniel, thanks for double-checking that!
Status: NEW → RESOLVED
Last Resolved: 4 years ago
Depends on: 833542
Resolution: --- → FIXED
Flags: in-testsuite?

Comment 10

4 years ago
Created attachment 742857 [details] [diff] [review]
add test

This is a patch which turns the previously supplied test case into a regression test.
Attachment #714089 - Attachment is obsolete: true
Attachment #742857 - Flags: review?
Attachment #742857 - Flags: review?
You need to log in before you can comment on or make changes to this bug.