Closed
Bug 349946
Opened 18 years ago
Closed 17 years ago
Nested div with style overflow:auto is visible when placed outside viewable area of container div with style overflow:hidden
Categories
(Core :: Web Painting, defect)
Tracking
()
RESOLVED
WORKSFORME
People
(Reporter: mikew, Assigned: roc)
References
Details
(Keywords: regression, testcase)
Attachments
(1 file)
6.59 KB,
text/html
|
Details |
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.0.6) Gecko/20060728 Firefox/1.5.0.6 Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.0.6) Gecko/20060728 Firefox/1.5.0.6 When a nested div whose overflow style is set to "auto" or "scroll" is programmatically placed outside the viewable area of its parent div, whose overflow style is set to "hidden," the nested div's contents (sans scrollbars, if they exist) are visible outside the bounds of the container div. This "phantom" div is visible until the window is forced to redraw itself (e.g., the window is resized or another window is dragged over it). I've also tested this on Mozilla/5.0(Windows; U; Windows NT 5.1; en-US; rv:1.8.1b1) Gecko/20060710 Firefox/2.0b1 and got the same result. This does not happen in IE. Reproducible: Always Steps to Reproduce: 1.Create a "container" div whose overflow is set to hidden. 2.Create a "nested" div and place it as a child of the container div. This nested div should have its overflow style set to auto (or scroll) and should be placed within the viewable area of the container. 3.Using javascript, change the style of the nested div so that it is (at least partially) outside the viewable area of the container div. (e.g., set the nested div's style.left="100%") Actual Results: Any portion of the nested div that was placed outside the container div's viewable area is visible until the window is resized or another window is dragged over it. Expected Results: The portion of the nested div that is outside the viewable area of the container div should be clipped, since the container div's overflow was set to hidden.
Reporter | ||
Comment 1•18 years ago
|
||
Updated•18 years ago
|
Component: General → Layout
Product: Firefox → Core
QA Contact: general → layout
Version: unspecified → 1.8 Branch
Comment 2•18 years ago
|
||
Yes, I can see the bug too on current trunk build (nice testcase!). I can't see the bug with a Mozilla1.7.12 build, so this is a regression.
Assignee: nobody → roc
Status: UNCONFIRMED → NEW
Component: Layout → Layout: View Rendering
Ever confirmed: true
Keywords: regression,
testcase
QA Contact: layout → ian
Version: 1.8 Branch → Trunk
Comment 3•18 years ago
|
||
This regressed between 2004-05-20 and 2004-05-26, so my guess would be a regression from bug 243882.
Blocks: 243882
Comment 4•18 years ago
|
||
So... The regression is between 2004-05-21-06 and 2004-05-22-08, which does indeed agree with the range for bug 243882. But if I back out that patch in a trunk build or 1.8 branch build, I still see this problem. If I replace the hint with a framechange hint the issue disappears... So something else is going on here. I have no idea what, offhand. :(
Flags: blocking1.9?
Updated•18 years ago
|
OS: Windows XP → All
Comment 5•18 years ago
|
||
This bug still has a status of 'NEW'. Now that you've replicated this bug...any chance of assignment and a fix?
Comment 7•18 years ago
|
||
Bug 352093 was created more than 4 YEARS ago. The big questions is: will it be fixed for Firefox 2.0?
Comment 8•18 years ago
|
||
Sorry I meant bug 130078 which bug 352093 depdends on is 4 years old.
Comment 9•18 years ago
|
||
> The big questions is: will it be fixed for Firefox 2.0?
Unlikely, since we haven't been able to figure out why it's happening yet and Firefox 2.0 is more or less in code-freeze as far as layout code is concerned.
If you feel that this is a must-fix for 2.0, please nominate it for blocking 1.8.1, of course.
Is this still a problem on the trunk?
Comment 11•17 years ago
|
||
Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9a3pre) Gecko/20070308 Minefield/3.0a3pre ID:2007030804 [cairo] Testcase now works for me; when clicking ">> set inner div's style.left=100%" for the 'Broken Example' the red box with the text no longer shifts over to the right hand side of the container, only to disappear when the browser window is resized. Instead it flickers slightly to the right hand side of the viewable area before properly disappearing.
Assignee | ||
Comment 12•17 years ago
|
||
Works for me on Mac too.
Status: NEW → RESOLVED
Closed: 17 years ago
Resolution: --- → WORKSFORME
Assignee | ||
Updated•17 years ago
|
Flags: blocking1.9?
Updated•17 years ago
|
Flags: in-testsuite?
Updated•12 years ago
|
Flags: in-testsuite?
Updated•6 years ago
|
Component: Layout: View Rendering → Layout: Web Painting
You need to log in
before you can comment on or make changes to this bug.
Description
•