[ABS POS] Scrollbar do not disappear when dragging an absolutely positioned element

RESOLVED FIXED

Status

()

Core
Layout: R & A Pos
RESOLVED FIXED
16 years ago
15 years ago

People

(Reporter: Gérard Talbot, Assigned: roc)

Tracking

({regression, testcase})

Trunk
regression, testcase
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(URL)

Attachments

(4 attachments)

(Reporter)

Description

16 years ago
When one drags-and-drop an absolutely positioned <div> so that its content
overflow outside the browser viewport, then scrollbar(s) appear. When dragging
such absolutely positioned <div> so that its content no longer overflow outside
the browser viewport, then scrollbar(s) do not disappear.

This phenomenon has been noticed on build 2002092617 and 2002100108 under XP Pro
SP1.
This phenomenon do not happen in NS 7.0 final release (20020823), so this is a
regression.
This phenomenon do not happen in MSIE 6 (furthermore if overflow-y:auto is
declared on the root element in compatMode == "CSS1Compat").

Reproducible: always.

A reduced test case will follow.
(Reporter)

Comment 1

16 years ago
Created attachment 101322 [details]
Self explanatory reduced test case

Drag and drop the blue <div> so that part of its content is outside the
boundaries of the browser viewport. This will make scrollbar(s) appear.
Then drag and drop the blue <div> back out so that all of its content is
inside, within the boundaries of the browser viewport.
The scrollbar(s) will not disappear and they should disappear.
Please test with tomorrow's builds.  Roc recently checked in some code that may
affect this testcase....
Summary: [ABS POS] Scrollbar do not disappear when dragging an absolutely positioned element → [ABS POS] Scrollbar do not disappear when dragging an absolutely positioned element
(Reporter)

Comment 3

16 years ago
Same scrollbar behavior in today's build (2002100208). The bug is still there.
Sounds like overflow areas are not being updated properly...  David, any ideas?
OS: Windows XP → All
Hardware: PC → All
Status: UNCONFIRMED → NEW
Ever confirmed: true
Perhaps it's a bug in the incremental reflow of absolutely positioned frames.
Note that if you resize the window the scrollbars disappear immediately.

Comment 6

16 years ago
regression between linux trunk builds 2002092221 and 2002092408
Keywords: regression
In other words, bug 75121 (which is what I suspected to begin with).

Comment 8

16 years ago
yes, backing out bug 75121 fixes this bug

Comment 9

16 years ago
*** Bug 174974 has been marked as a duplicate of this bug. ***

Comment 10

16 years ago
This can also be seen at:
resource:///res/samples/test13.html

Updated

16 years ago
Keywords: mozilla1.2

Updated

16 years ago
Keywords: mozilla1.3

Comment 11

16 years ago
Is bug 75121 being backed out or is this bug getting fixed another way? 

Comment 12

16 years ago
Just a clarifying comment in case it isn't clear from the original description: 
This has nothing to do with drag and drop. If an absolutely positioned div is 
outside the viewport and then positioned inside it (such as with JavaScript in 
an onload event) the scrollbars will not disappear. Resizing the window will 
cause the scrollbars to restore to what they should be.

Comment 13

16 years ago
Created attachment 107596 [details]
testcase with div positioned onload

Updated

16 years ago
Keywords: testcase
Created attachment 107809 [details]
testcase showing problem doesn't exist in general case

This testcase tests contraction of scrollbars for incremental reflow (or what
should be incremental reflow, anyway), and shows that the problem doesn't exist
in the general case.
I'd be interested to see what happens with this testcase once roc relands his
overflow changes (which I think should be relanded based on recent CSS WG
discussion).  (I wonder how those changes handle incremental reflow if these
don't even handle it correctly.  Or do they manage to help?)
Component: Layout → Layout: R & A Pos
(I think the long term solution to this bug (and perhaps to the auto-offsets
problem as well) is to reflow absolutely positioned elements through their
placeholders, like we do for floaters.  This would mean that the reflow
recursion would essentially be over the content tree rather than the frame tree.
 If we actually want to do that, we might want to simultaneously make the style
tree isomorphic to the content tree rather than the frame tree.)
This is mine. I will fix this before doing anything else because something in
the incremental reflow logic is clearly busted.
Assignee: attinasi → roc+moz
What's clearly busted?  (Is the containing block of the absolutely positioned
elements inside the ancestor of those elements that has 'overflow: scroll'?)  If
so, then I can see that something is clearly busted, but if not, I only see a
rather serious design flaw.)
OK, so the bug is that nsCanvasFrame sets the width and height of the block it
contains to include the block's overflow area. Later when the absolute child is
incrementally reflowed, nsBlockFrame::Reflow sets its preferred width and height
to the current width and height, which now includes the overflow area so we lose.

My solution is to have nsCanvasFrame save the original desired width and height
and restore them just before reflowing the block (if it's an incremental
reflow). Patch coming up.
Created attachment 107996 [details] [diff] [review]
Fix

This is arguably a hack. However I think it's the right thing because IMHO
nsCanvasFrame should not be changing the block's desired size. This patch keeps
the logic to correct this original hack in the same place as the original hack
itself.
Attachment #107996 - Flags: superreview?(kin)
Attachment #107996 - Flags: review?(karnaze)

Comment 21

16 years ago
>>nsCanvasFrame should not be changing the block's desired size.
 
What should it be doing? Is there some other bug that stops using mOverflowArea
in reflow?


The canvas frame wants to size itself to enclose the overflow area so that you
can scroll to see all the absolutely positioned elements even if they're outside
the document root element itself. Ideally it would suffice for the canvas frame
to size itself and leave its block child alone. However, I'm not sure. In
particular, I think we may need to resize the block to make borders and
backgrounds look right.

Comment 23

16 years ago
Comment on attachment 107996 [details] [diff] [review]
Fix

There may be a better way to do this, but I can't think of it right now. This
patch is better than the alternative. r=karnaze.
Attachment #107996 - Flags: review?(karnaze) → review+

Comment 24

16 years ago
Comment on attachment 107996 [details] [diff] [review]
Fix

sr=kin@netscape.com
Attachment #107996 - Flags: superreview?(kin) → superreview+
Fix checked in.
Status: NEW → RESOLVED
Last Resolved: 16 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.