303676 - absolute top:auto does not move when scrolled

Status: NEW

(Core :: Layout: Positioned, defect)

Description

[Dave Townsend [:mossop]]

When an absolutely positioned element only has one of its coordinates specified,
the other is re-calculated when the page is focussed.

In the upcoming testcase there is a main div with overflow:auto and a load of
padding text. There is also an absolutely positioned div with only its right
position set. It makes itself appear at the top of the scrollable div. When you
scroll down the div remains visible, until you focus the page either by right
clicking on it or tabbing to it.

I believe that the positioned div should remain at the top of the scrollable
area at the top and so should vanish as you scroll, not waiting for you to do
something else. Opera and IE both behave this way.

Seen in Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b4) Gecko/20050804
Firefox/1.0+ ID:2005080406

Comment 1

[Dave Townsend [:mossop]]

Attachment: Testcase

Comment 2

[Frank Wein [:mcsmurf]]

BTW: "1. The page appears with a green box in the top left"
Should this read "top right"? Here the green box is on the right side.

Comment 3

[Dave Townsend [:mossop]]

Yes, it should be the right hand side. just a mistype on my part.

Comment 4

[Mats Palmgren (inactive)]

Attachment: Simplified testcase

Comment 5

[Mats Palmgren (inactive)]

Attachment: Better testcase

Comment 6

[Mats Palmgren (inactive)]

(In reply to comment #0)
> I believe that the positioned div should remain at the top of the scrollable
> area at the top 

Yes, top:auto means we should use the static y-position which moves
when you scroll here.

> and so should vanish as you scroll, not waiting for you to do
> something else. Opera and IE both behave this way.

No, I believe IE and Opera is wrong here, clipping E's content does not affect
descendants of E whose containing block is an ancestor of E.
http://www.w3.org/TR/CSS21/visufx.html#propdef-overflow

So, I think we should scroll it but not clip it.

Comment 7

[Mats Palmgren (inactive)]

Attachment: Testcase #2

Comment 8

[Mats Palmgren (inactive)]

Attachment: Testcase #3 (fixed pos.)

Comment 9

[Mats Palmgren (inactive)]

Attachment: Testcase #4 (absolute pos.)

Comment 10

[Mats Palmgren (inactive)]

Attachment: Patch rev. 1

BTW, does anyone know the reasoning behind the note in 10.3.7 that fixed auto
pos.
should assume all scroll boxes to be scrolled to their origin?

Comment 11

[Mats Palmgren (inactive)]

Comment on attachment 191904 [details] [diff] [review]
Patch rev. 1

FWIW, if I remove "display->mPosition == NS_STYLE_POSITION_ABSOLUTE"
when setting the view flags it makes fixed auto pos. also track the
placeholder on scrolls.

Comment 12

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

(In reply to comment #10)
> BTW, does anyone know the reasoning behind the note in 10.3.7 that fixed auto
> pos. should assume all scroll boxes to be scrolled to their origin?

Otherwise they wouldn't be fixed.

Comment 13

[Mats Palmgren (inactive)]

Comment on attachment 191904 [details] [diff] [review]
Patch rev. 1

Note to self: rev the IID for nsIView.

Comment 14

[Robert O'Callahan (:roc) (email my personal email if necessary)]

This is trickier than it looks.

I think this patch isn't quite right because it doesn't move the absolute frame,
just the view. Thus I think weird things could happen because the frame and view
get out of sync.

In particular there's one very nasty thing that could happen. Scrolling an
overflow:auto element could move the absolute frame in such a way that it causes
a scrollbar to appear on an outer scrollable frame (e.g., the viewport). This
would need to trigger a reflow, which normally can't happen during scrolling!

This is not a regression and it's pretty special case so we might want to put it
off until 1.9. And it might be easier to handle once we've merged views into frames.

Comment 15

[Boris Zbarsky [:bzbarsky]]

Note that this is still an issue on trunk, even though we've moved away from using views in many cases.

Comment 16

[Stephen Donner [:stephend] Not actively reading bugmail]

Mass-removing myself from cc; search for 12b9dfe4-ece3-40dc-8d23-60e179f64ac1 or any reasonable part thereof, to mass-delete these notifications (and sorry!)