The default bug view has changed. See this FAQ.

absolute top:auto does not move when scrolled

NEW
Unassigned

Status

()

Core
Layout: R & A Pos
12 years ago
8 years ago

People

(Reporter: mossop, Unassigned)

Tracking

({testcase})

Trunk
x86
All
testcase
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(4 attachments, 3 obsolete attachments)

(Reporter)

Description

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

Comment 1

12 years ago
Created attachment 191800 [details]
Testcase
(Reporter)

Updated

12 years ago
Keywords: testcase

Comment 2

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

Comment 3

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

Comment 4

12 years ago
Created attachment 191844 [details]
Simplified testcase
Attachment #191800 - Attachment is obsolete: true

Updated

12 years ago
OS: Windows XP → All

Comment 5

12 years ago
Created attachment 191858 [details]
Better testcase
Attachment #191844 - Attachment is obsolete: true

Comment 6

12 years ago
(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.
Assignee: nobody → mats.palmgren
Summary: Absolute positioned elements are repositioned on page focus → absolute top:auto does not move when scrolled

Comment 7

12 years ago
Created attachment 191861 [details]
Testcase #2

Comment 8

12 years ago
Created attachment 191901 [details]
Testcase #3 (fixed pos.)

Comment 9

12 years ago
Created attachment 191902 [details]
Testcase #4 (absolute pos.)
Created attachment 191904 [details] [diff] [review]
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?
Attachment #191904 - Flags: superreview?(roc)
Attachment #191904 - Flags: review?(bzbarsky)
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.
(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 on attachment 191904 [details] [diff] [review]
Patch rev. 1

Note to self: rev the IID for nsIView.
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.
Attachment #191904 - Flags: superreview?(roc)
Attachment #191904 - Flags: superreview-
Attachment #191904 - Flags: review?(bzbarsky)

Updated

12 years ago
Attachment #191904 - Attachment is obsolete: true

Updated

12 years ago
Assignee: mats.palmgren → nobody
Note that this is still an issue on trunk, even though we've moved away from using views in many cases.
You need to log in before you can comment on or make changes to this bug.