Closed Bug 241304 Opened 21 years ago Closed 21 years ago

div overflow: hidden position: fixed shows scrollbar with a containing div

Categories

(Core :: Web Painting, defect)

Product:
Core
Component:
Web Painting
Type:
defect
Priority:
Not set
Severity:
major

Tracking

()

Status:
RESOLVED FIXED

People

(Reporter: jeroen, Assigned: roc)

References

Details

(Keywords: fixed1.7, regression)

Attachments

(2 files)

Testcase
916 bytes, text/html
Details
Roc's proposed fix
1010 bytes, patch
bzbarsky
: review+
bzbarsky
: superreview+
dbaron
: approval1.7+
Details | Diff | Splinter Review
User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.6) Gecko/20040206 Firefox/0.8 Build Identifier: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.7b) Gecko/20040421 When I create a div with style= position:fixed; overflow:hidden; and in this fixed div I place another div with position:absolute and the height of this div is higher then the parent div, a scrollbar is shown, previous versions (1.7beta and below) didn't show a scrollbar which is what I expected. Reproducible: Always Steps to Reproduce: 1. Create a document with the following contents: <!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"> <html> <head> <meta content="text/html; charset=ISO-8859-1" http-equiv="content-type"> <title>overflow test</title> </head> <body> <div style="border: 1px solid grey; width: 100ex; height: 10ex; overflow: hidden; position: fixed;"> <div style="width: 10ex; height: 20ex; position: absolute; background-color: red;"> - </div> This is text, this is text, this is text, this is text, this is text, this is text, this is text </div> </body> </html> 2. Open the file in mozilla Actual Results: The document loads, but a scrollbar is shown in the first div. Expected Results: A scrollbar should not be shown because of the style overflow: hidden;
What W3C recommandations say about the scrollbar?
Here is the answer, from CSS 2.1 (dated February 25., 2004), about overflow properties: *hidden* This value indicates that the content is clipped and that no scrolling user interface should be provided to view the content outside the clipping region. *scroll* This value indicates that the content is clipped and that if the user agent uses a scrolling mechanism that is visible on the screen (such as a scroll bar or a panner), that mechanism should be displayed for a box whether or not any of its content is clipped. This avoids any problem with scrollbars appearing and disappearing in a dynamic environment. Then the reporter is right and Mozilla 1.7 behaves incorrectly.
Attached file Testcase —
Confirming. Jeroen, you're reporting this against 1.7rc1, right? If not, please say so ASAP so we don't waste time looking at the wrong code.... This regressed on trunk the day 1.8a opened for checkins. Checkins for that day: http://bonsai.mozilla.org/cvsquery.cgi?treeid=default&module=all&branch=HEAD&branchtype=match&dir=&file=&filetype=match&who=&whotype=match&sortby=Date&hours=2&date=explicit&mindate=2004-04-12+08%3A00%3A00&maxdate=2004-04-13+09%3A00%3A00&cvsroot=%2Fcvsroot Since this is also showing up in 1.7rc1, apparently, we have to intersect that list of checkins with the list at http://bonsai.mozilla.org/cvsquery.cgi?treeid=default&module=all&branch=MOZILLA_1_7_BRANCH&branchtype=match&dir=&file=&filetype=match&who=&whotype=match&sortby=Date&hours=2&date=all&mindate=&maxdate=&cvsroot=%2Fcvsroot Which doesn't leave many options, does it? If someone can grab some branch nigtlies and find when this broke on the branch, that would help a ton. My bet is that it broke on the afternoon of April 13 and that bug 234851 is responsible... This is a pretty serious regression...
Severity: normal → major
Status: UNCONFIRMED → NEW
Ever confirmed: true
Flags: blocking1.7?
I've verified (via local backout) that bug 231166, bug 240291, and bug 234761 are not responsible for this regression...
Keywords: regression
OK, I have also verified via local backout that bug 234851 _did_ cause this.
Depends on: 234851
And the problem is the change in nsGfxScrollFrame.cpp: - PRInt32 overflow = GetStyleDisplay()->mOverflow; + PRUint8 overflow; + if (GetParent() && GetParent()->GetType() == nsLayoutAtoms::viewportFrame) { + overflow = GetPresContext()->GetViewportOverflowOverride(); + } else { + overflow = GetStyleDisplay()->mOverflow; + } This should only be done if position is not fixed, since fixed-pos frames _are_ kids of the viewport.
Patch wanted for 1.7's next RC. /be
Flags: blocking1.7? → blocking1.7+
I'll probably have a patch in 30 mins or so (well, I have it now, but need to build and test).
I'm having DSL problems and can't get to CVS from home. Also, email to me @ocallahan.org will be bouncing. The fix should be something like this: if (GetParent() && GetParent()->GetType() == nsLayoutAtoms::viewportFrame + && GetParent()->GetFirstChild(nsnull) == this) { Since fixed position children are on a different child list, and the viewport scrollframe is always the first (and only) child of the viewport.
Summary: div overflow: hidden position: fixed shows scrollbar with a containting div → div overflow: hidden position: fixed shows scrollbar with a containing div
This is better than what I had.
Comment on attachment 146800 [details] [diff] [review] Roc's proposed fix r+sr=bzbarsky. This should be plenty safe to go on branch.
Attachment #146800 - Flags: superreview+
Attachment #146800 - Flags: review+
Attachment #146800 - Flags: approval1.7?
Comment on attachment 146800 [details] [diff] [review] Roc's proposed fix Checked in on the 1.8a trunk.
I'm fixing bustage for this checkin -- don't forget the bustage fix when going to the branch.
Thanks for catching that.... Checked in to 1.7 branch, with bustage fix included.
Status: NEW → RESOLVED
Closed: 21 years ago
Keywords: fixed1.7
Resolution: --- → FIXED
*** Bug 242660 has been marked as a duplicate of this bug. ***
Component: Layout: View Rendering → Layout: Web Painting
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: