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
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.
Yes, it should be the right hand side. just a mistype on my part.
Created attachment 191844 [details] Simplified testcase
Attachment #191800 - Attachment is obsolete: true
Created attachment 191858 [details] Better testcase
Attachment #191844 - Attachment is obsolete: true
(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
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 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.
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.