Last Comment Bug 303676 - absolute top:auto does not move when scrolled
: absolute top:auto does not move when scrolled
Status: NEW
: testcase
Product: Core
Classification: Components
Component: Layout: R & A Pos (show other bugs)
: Trunk
: x86 All
: -- normal with 2 votes (vote)
: ---
Assigned To: Nobody; OK to take it and work on it
:
Mentors:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2005-08-06 06:20 PDT by Dave Townsend [:mossop]
Modified: 2009-04-21 05:39 PDT (History)
6 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments
Testcase (1.94 KB, text/html)
2005-08-06 06:20 PDT, Dave Townsend [:mossop]
no flags Details
Simplified testcase (1.25 KB, text/html)
2005-08-06 16:41 PDT, Mats Palmgren (:mats)
no flags Details
Better testcase (619 bytes, text/html)
2005-08-06 20:46 PDT, Mats Palmgren (:mats)
no flags Details
Testcase #2 (635 bytes, text/html)
2005-08-06 21:43 PDT, Mats Palmgren (:mats)
no flags Details
Testcase #3 (fixed pos.) (1.57 KB, text/html)
2005-08-07 12:48 PDT, Mats Palmgren (:mats)
no flags Details
Testcase #4 (absolute pos.) (1.60 KB, text/html)
2005-08-07 12:50 PDT, Mats Palmgren (:mats)
no flags Details
Patch rev. 1 (5.46 KB, patch)
2005-08-07 12:59 PDT, Mats Palmgren (:mats)
roc: superreview-
Details | Diff | Splinter Review

Description Dave Townsend [:mossop] 2005-08-06 06:20:05 PDT
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] 2005-08-06 06:20:46 PDT
Created attachment 191800 [details]
Testcase
Comment 2 Frank Wein [:mcsmurf] 2005-08-06 06:42:17 PDT
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] 2005-08-06 06:52:43 PDT
Yes, it should be the right hand side. just a mistype on my part.
Comment 4 Mats Palmgren (:mats) 2005-08-06 16:41:12 PDT
Created attachment 191844 [details]
Simplified testcase
Comment 5 Mats Palmgren (:mats) 2005-08-06 20:46:37 PDT
Created attachment 191858 [details]
Better testcase
Comment 6 Mats Palmgren (:mats) 2005-08-06 21:11:34 PDT
(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 (:mats) 2005-08-06 21:43:30 PDT
Created attachment 191861 [details]
Testcase #2
Comment 8 Mats Palmgren (:mats) 2005-08-07 12:48:52 PDT
Created attachment 191901 [details]
Testcase #3 (fixed pos.)
Comment 9 Mats Palmgren (:mats) 2005-08-07 12:50:12 PDT
Created attachment 191902 [details]
Testcase #4 (absolute pos.)
Comment 10 Mats Palmgren (:mats) 2005-08-07 12:59:15 PDT
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?
Comment 11 Mats Palmgren (:mats) 2005-08-07 13:04:51 PDT
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-7 (review requests must explain patch) 2005-08-07 13:05:57 PDT
(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 (:mats) 2005-08-07 16:11:07 PDT
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) 2005-08-07 18:07:35 PDT
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 [:bz] 2009-04-21 05:39:50 PDT
Note that this is still an issue on trunk, even though we've moved away from using views in many cases.

Note You need to log in before you can comment on or make changes to this bug.