98579 - bottom and right don't work if height and/or width not specified

Status: RESOLVED FIXED

(Core :: Layout, defect, P2)

Description

[Millennium]

From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:0.9.3+) Gecko/20010906
BuildID:    2001090603

When using fixed positioning, if an element's height is not explicitly set, then
the bottom: property does not work. The element is either not rendered at all,
or it is rendered somewhere offscreen (I can't tell which). See the attachment
for details.

Reproducible: Always
Steps to Reproduce:
1. Load the attachment (postest.html). The yellow box will start
statically-positioned.
2. Click "Absolute" to change the box's positioning to absolute.
3. Observe the position of the yellow box.
4. Click "Fixed" to change the box's positioning to fixed.
5. Observe the position of the yellow box.

Actual Results:  In absolute positioning, the box moves near the bottom of the
screen, but not ten pixels from the right or bottom, as it should.

In fixed positioning, the yellow box does not appear to be rendered at all; it
does not appear in the window.

Expected Results:  The yellow box moves to a position where it is ten pixels
from the bottom and ten pixels from the right of the window. This should apply
whether the positioning is absolute or fixed.

Comment 1

[Millennium]

Attachment: Demonstration of problem

Comment 2

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

Attachment: slightly modified form of testcase (fixed is initial state)

Comment 3

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

We're really sending it off into the middle of nowhere:
Fixed-list<
  Area(p)(11)@0x8311804 [view=0x8312a48] {1073741824,1073742016,7068,768}
[state=00c02104] sc=0x8311888(i=4,b=0)<

Comment 4

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

1073741824 == 2^30

Comment 5

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

The relevant parts of CSS2 that say what should happen are 10.3.7:
http://www.w3.org/TR/REC-CSS2/visudet.html#abs-non-replaced-width
and 10.1:
http://www.w3.org/TR/REC-CSS2/visudet.html#containing-block-details

Comment 6

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

The problem seems to be that nsHTMLReflowState::InitAbsoluteConstraints sets
mComputedOffsets.{left,top} to NS_AUTOOFFSET, and we just end up using that
value as a number:

        if (leftIsAuto) {
          mComputedOffsets.left = NS_AUTOOFFSET;   // solve for 'left'
        } else {
          mComputedOffsets.right = NS_AUTOOFFSET;  // solve for 'right'
        }

Comment 7

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

Attachment: fix for this problem

Comment 8

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

This patch fixes the immediate problem here.  However, the differences between
ReflowAbsoluteFrame and ReflowFixedFrame suggest to me that there are some other
problems lurking here -- perhaps some bugs in ReflowFixedFrame, or perhaps some
unneeded code in ReflowAbsoluteFrame, or at code that won't be needed if we find
a better way to reposition views.  (Here's yet another case of weird frames
moving after view positioning stuff.)

Comment 9

[Chris Waterson]

The changes you've made look fine; r= or sr=waterson, whichever helps.

Given the current way we do views (which actually seems more reasonable to me
now that kmcclusk has explained it to me), I think that
ViewportFrame::ReflowFixedFrame really ought to call
nsContainerFrame::PositionChildViews (or, perhaps we ought to modify
nsContainerFrame::SyncFrameViewAfterReflow to do so). It does seem that if the
kid's left or top should move during reflow (can it? perhaps not?), we may end
up with a situation where a child view could be positioned incorrectly.

The same is almost certainly true in
nsAbsoluteContainingBlock::ReflowAbsoluteFrame. I'll go ahead and try to concoct
test cases to illustrate the problems.

Comment 10

[Chris Waterson]

Filed bug 99978 for above issue.

Comment 11

[Marc Attinasi]

Comment on attachment 49466 [details] [diff] [review]
fix for this problem

sr=attinasi

Comment 12

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

Fix checked in 2001-09-17 16:55 PDT.

Comment 13

[Boris Zbarsky [:bzbarsky]]

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