126213 - [FIX]fixed or absolute positioned div with { bottom: 0 } does not render flush against bottom of viewport (leaves space) [CSS/stylesheet bug]

Status: VERIFIED FIXED

(Core :: Layout, defect, P1)

Description

[m_mozilla]

try test case
    http://wickline.org/mozilla/2002021800/
    in mozilla 2002021413

footer block (grey) should render flush with bottom/right corner. It renders
flush with the right edge, but not with the bottom edge (note body background
color showing through at bottom of viewport.

MSIE 5.x for the mac handles this correctly.
(is there some parity keyword or something for that?)

-matt

Comment 1

[m_mozilla]

bug 80904 sounds kinda simmilar, but is about XUL stuff. Is there any connection?

Comment 2

[Boris Zbarsky [:bzbarsky]]

Confirmed on Linux 2002-02-18-08.  Decreasing the padding on the div moves it
closer to the edge for some reason (why???) but there is always a 6px or so gap
there.

Comment 3

[m_mozilla]

I hope that's correct usage of the status whiteboard... saw it in bug 126213

fixing typo in summary, adding more words to make it more findable

-matt

Comment 4

[m_mozilla]

errr.... saw it in bug 58305 rather

(recursive humor completely accidental ;)

Comment 5

[Boris Zbarsky [:bzbarsky]]

that div is not floated

Comment 6

[m_mozilla]

update:

still seeing this in 1.0 trunk build 2002051205 Mac OS X

I don't know if this is a coincidence, but it *looks* like the offset from the
bottom of the viewport is the same height as a window's horizontal scrollbar. Is
there some math error allowing room for an extra scrollbar?

Normally when I view the example, my window has no scrollbar. If I resize the
window to be narrow enough to cause a horizontal scrollbar to appear, we still
have the same amount of extra space. It is not the case that there is room left
for a scrollbar, which then gets filled by the scrollbar when available. If the
scrollbar is at all related, it just seems to be that mozilla consistently
leaves space for an extra one.

-matt

Comment 7

[Boris Zbarsky [:bzbarsky]]

Attachment: A testcase that shows that this is a problem with width:auto as well.

Comment 8

[Boris Zbarsky [:bzbarsky]]

Attachment: The real testcase that shows that this is a problem with width:auto as well

Comment 9

[Boris Zbarsky [:bzbarsky]]

Attachment: Patch v 1.0

So the problem is that the HTMLReflowMetrics' width and height members are the
width and height _including_ the padding and borders (see how we size the rect
for the frame).  So the code we had was double-counting them when determining
the computed value of "auto" top/bottom.  As a result, the frame was placed too
high by border-top + padding-top + +padding-bottom + border-bottom.

Comment 10

[Boris Zbarsky [:bzbarsky]]

Attachment: testcase showing that position:absolute suffers from the same problem

This testcase is based on bug 134518, with position:absolute instead of
position:fixed.

Comment 11

[Boris Zbarsky [:bzbarsky]]

Attachment: Patch v1.5

Fix abs pos as well.

As a note (I forgot this in comment 9) the reason I moved the "// XXX" code in
nsViewportFrame is that we should be using the height we will use for the frame
rect in calculating the frame rect's origin....

Comment 12

[Boris Zbarsky [:bzbarsky]]

*** Bug 134518 has been marked as a duplicate of this bug. ***

Comment 13

[Boris Zbarsky [:bzbarsky]]

taking bug

Comment 14

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Comment on attachment 83923 [details] [diff] [review]
Patch v1.5

r=dbaron if you change all of the things of this form:

>+      kidDesiredSize.height = kidReflowState.mComputedHeight;
>+      kidDesiredSize.height += kidReflowState.mComputedBorderPadding.top +
>+        kidReflowState.mComputedBorderPadding.bottom;

to

kidDesiredSize.height = kidReflowState.mComputedHeight +
			kidReflowState.mComputedBorderPadding.top +
			kidReflowState.mComputedBorderPadding.bottom;

Comment 15

[Boris Zbarsky [:bzbarsky]]

Attachment: Patch v1.51

make that cosmetic change

Comment 16

[Marc Attinasi]

Comment on attachment 83932 [details] [diff] [review]
Patch v1.51

sr=attinasi (and carrying over dbaron's r= to this patch as well)

Comment 17

[Boris Zbarsky [:bzbarsky]]

Checked in on the trunk.

Comment 18

[Boris Zbarsky [:bzbarsky]]

*** Bug 147109 has been marked as a duplicate of this bug. ***

Comment 19

[m_mozilla]

verified fixed Mac OS X trunk build 2002052103

-matt

Comment 20

[Boris Zbarsky [:bzbarsky]]

request sent for approval to land on the branch for 1.0.1...

Comment 21

[Judson Valeski]

please checkin to the 1.0.1 branch ASAP. once there please remove the
mozilla1.0.1+ keyword and add the fixed1.0.1 keyword.

Comment 22

[Boris Zbarsky [:bzbarsky]]

fixed on 1.0.1 branch

Comment 23

[Chris Petersen]

Verified in the branch OS X (2002-07-16-05) and Windows ME (2002-07-16-08).