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

Status: RESOLVED FIXED

(Core :: Layout: Positioned, defect)

Description

[Gérard Talbot]

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.

Comment 1

[Gérard Talbot]

Attachment: 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.

Comment 2

[Boris Zbarsky [:bzbarsky]]

Please test with tomorrow's builds.  Roc recently checked in some code that may
affect this testcase....

Comment 3

[Gérard Talbot]

Same scrollbar behavior in today's build (2002100208). The bug is still there.

Comment 4

[Boris Zbarsky [:bzbarsky]]

Sounds like overflow areas are not being updated properly...  David, any ideas?

Comment 5

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

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

[Andrew Schultz]

regression between linux trunk builds 2002092221 and 2002092408

Comment 7

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

In other words, bug 75121 (which is what I suspected to begin with).

Comment 8

[Andrew Schultz]

yes, backing out bug 75121 fixes this bug

Comment 9

[José Jeria]

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

Comment 10

[José Jeria]

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

Comment 11

[Susie Wyshak]

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

Comment 12

[Tim Powell]

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

[Tim Powell]

Attachment: testcase with div positioned onload

Comment 14

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

Attachment: 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.

Comment 15

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

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?)

Comment 16

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

(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.)

Comment 17

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

This is mine. I will fix this before doing anything else because something in
the incremental reflow logic is clearly busted.

Comment 18

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

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.)

Comment 19

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

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.

Comment 20

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

Attachment: 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.

Comment 21

[karnaze (gone)]

>>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?

Comment 22

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

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

[karnaze (gone)]

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.

Comment 24

[kinmoz]

Comment on attachment 107996 [details] [diff] [review]
Fix

sr=[e-mail]

Comment 25

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

Fix checked in.