Closed
Bug 172031
Opened 22 years ago
Closed 22 years ago
[ABS POS] Scrollbar do not disappear when dragging an absolutely positioned element
Categories
(Core :: Layout: Positioned, defect)
Core
Layout: Positioned
Tracking
()
RESOLVED
FIXED
People
(Reporter: bugzilla, Assigned: roc)
References
()
Details
(Keywords: regression, testcase)
Attachments
(4 files)
2.83 KB,
text/html
|
Details | |
1.00 KB,
text/html
|
Details | |
1.19 KB,
text/html
|
Details | |
1.55 KB,
patch
|
karnaze
:
review+
kinmoz
:
superreview+
|
Details | Diff | Splinter Review |
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•22 years ago
|
||
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•22 years ago
|
||
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•22 years ago
|
||
Same scrollbar behavior in today's build (2002100208). The bug is still there.
Comment 4•22 years ago
|
||
Sounds like overflow areas are not being updated properly... David, any ideas?
OS: Windows XP → All
Hardware: PC → All
Updated•22 years ago
|
Status: UNCONFIRMED → NEW
Ever confirmed: true
Assignee | ||
Comment 5•22 years ago
|
||
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•22 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 9•22 years ago
|
||
*** Bug 174974 has been marked as a duplicate of this bug. ***
Comment 10•22 years ago
|
||
This can also be seen at: resource:///res/samples/test13.html
Updated•22 years ago
|
Keywords: mozilla1.2
Updated•22 years ago
|
Keywords: mozilla1.3
Comment 11•22 years ago
|
||
Is bug 75121 being backed out or is this bug getting fixed another way?
Comment 12•22 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•22 years ago
|
||
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.)
Assignee | ||
Comment 17•22 years ago
|
||
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.)
Assignee | ||
Comment 19•22 years ago
|
||
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.
Assignee | ||
Comment 20•22 years ago
|
||
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.
Assignee | ||
Updated•22 years ago
|
Attachment #107996 -
Flags: superreview?(kin)
Attachment #107996 -
Flags: review?(karnaze)
Comment 21•22 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?
Assignee | ||
Comment 22•22 years ago
|
||
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•22 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•22 years ago
|
||
Comment on attachment 107996 [details] [diff] [review] Fix sr=kin@netscape.com
Attachment #107996 -
Flags: superreview?(kin) → superreview+
Assignee | ||
Comment 25•22 years ago
|
||
Fix checked in.
Status: NEW → RESOLVED
Closed: 22 years ago
Resolution: --- → FIXED
You need to log in
before you can comment on or make changes to this bug.
Description
•