Padding gets added at both sides when overflow is used

RESOLVED FIXED

Status

()

P3
normal
RESOLVED FIXED
11 years ago
11 years ago

People

(Reporter: daniel, Assigned: roc)

Tracking

({regression, testcase})

Trunk
x86
All
regression, testcase
Points:
---
Dependency tree / graph
Bug Flags:
blocking1.9 +
in-testsuite +

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [dbaron-1.9:RwCr])

Attachments

(4 attachments)

(Reporter)

Description

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

Comment 1

11 years ago
Created attachment 268782 [details]
HTML testcase
(Reporter)

Updated

11 years ago
Keywords: testcase
Blocks: 300030
Version: unspecified → Trunk
Component: Style System (CSS) → Layout: Block and Inline
QA Contact: style-system → layout.block-and-inline

Comment 2

11 years ago
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+

Comment 3

11 years ago
Created attachment 272690 [details] [diff] [review]
Patch

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.

Comment 5

11 years ago
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+

Comment 7

11 years ago
Checked in with reftest.
Status: ASSIGNED → RESOLVED
Last Resolved: 11 years ago
Flags: in-testsuite+
Resolution: --- → FIXED
(Reporter)

Comment 8

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

Comment 9

11 years ago
Created attachment 284271 [details]
Screenshot from 1.9a9pre

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]

Updated

11 years ago
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
Last Resolved: 11 years ago11 years ago
Resolution: --- → FIXED
(Reporter)

Comment 11

11 years ago
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.

Comment 12

11 years ago
Created attachment 290509 [details]
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.
(Reporter)

Comment 14

11 years ago
Hmmm... well.
bug 405952 filed.
You need to log in before you can comment on or make changes to this bug.