Closed Bug 384876 Opened 13 years ago Closed 13 years ago

Padding gets added at both sides when overflow is used

Categories

(Core :: Layout: Block and Inline, defect, P3)

x86
All
defect

Tracking

()

RESOLVED FIXED

People

(Reporter: daniel, Assigned: roc)

References

Details

(Keywords: regression, testcase, Whiteboard: [dbaron-1.9:RwCr])

Attachments

(4 files)

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.8.1.4) Gecko/20070515 Firefox/2.0.0.4
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; de-DE; rv:1.9a6pre) Gecko/20070617

When defining a padding for one side and set overflow to "auto" or "hidden", the padding is added at both sides. (This worked with Firefox 2.0.0.4)

Reproducible: Always
Attached file HTML testcase
Keywords: testcase
Version: unspecified → Trunk
Component: Style System (CSS) → Layout: Block and Inline
QA Contact: style-system → layout.block-and-inline
Confirming, and noting the following comment:
http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/layout/generic/nsGfxScrollFrame.cpp&rev=3.307&mark=678#678

I can't find a bug to dup this to, although that doesn't mean there isn't one on file...
Status: UNCONFIRMED → NEW
Ever confirmed: true
Flags: blocking1.9?
Flags: blocking1.9? → blocking1.9+
Attached patch PatchSplinter Review
GetPrefWidth should be correct here because a scrollframe isn't a normal container.
Assignee: nobody → sharparrow1
Status: NEW → ASSIGNED
Attachment #272690 - Flags: review?(roc)
Comment on attachment 272690 [details] [diff] [review]
Patch

>+    // XXX This isn't really right; we shouldn't be adding in space
>+    // for a vertical scrollbar when we might not need it

Yes we should.
Fine; consider the comment gone.  (It does lead to slightly odd-looking results with this testcase, but I suppose that's expected.)
Comment on attachment 272690 [details] [diff] [review]
Patch

minus the comment
Attachment #272690 - Flags: superreview+
Attachment #272690 - Flags: review?(roc)
Attachment #272690 - Flags: review+
Checked in with reftest.
Status: ASSIGNED → RESOLVED
Closed: 13 years ago
Flags: in-testsuite+
Resolution: --- → FIXED
I still see a difference in the latest trunk compared to Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.8.1.7) Gecko/20070914 Firefox/2.0.0.7
The third line in the testcase using overflow:auto has a bottom border that's about 16px larger than expected.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
The screenshot shows the extra padding at the third line.
Used build: XULRunner, Mozilla/5.0 (Windows; U; Windows NT 5.1; de-DE; rv:1.9a9pre) Gecko/2007100911
Whiteboard: [dbaron-1.9:RwCr]
Keywords: regression
OS: Windows XP → All
Assignee: sharparrow1 → roc
Status: REOPENED → NEW
Priority: -- → P3
I think comment #8 is simply caused by comment #4... we're adding the width of a scrollbar to the overflow:auto case. David says we should, I don't disagree. Closing this FIXED since it really was.
Status: NEW → RESOLVED
Closed: 13 years ago13 years ago
Resolution: --- → FIXED
I don't agree. Why is the padding added even when no scrollbar is needed?
In 1.8 no padding was added, IE doesn't add one, Opera doesn't add one too. Only Mozilla 1.9 releases shows this unexpected behaviour.
Attached image screenshot of testcase
From top to Bottom: Gecko 1.9, Opera 9.5b, WebKit build
As seen on OS X 10.4.11
OK, file a new bug, because it's definitely not this bug. David should make the call on this one.
Hmmm... well.
bug 405952 filed.
You need to log in before you can comment on or make changes to this bug.