2.83 KB, text/html
1.00 KB, text/html
1.19 KB, text/html
1.55 KB, patch
karnaze (gone): review+
|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.
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
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.
regression between linux trunk builds 2002092221 and 2002092408
In other words, bug 75121 (which is what I suspected to begin with).
yes, backing out bug 75121 fixes this bug
*** Bug 174974 has been marked as a duplicate of this bug. ***
This can also be seen at: resource:///res/samples/test13.html
Is bug 75121 being backed out or is this bug getting fixed another way?
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.
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 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 on attachment 107996 [details] [diff] [review] Fix email@example.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.