Closed Bug 241304 Opened 20 years ago Closed 20 years ago

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

Categories

(Core :: Web Painting, defect)

defect
Not set
major

Tracking

()

RESOLVED FIXED

People

(Reporter: jeroen, Assigned: roc)

References

Details

(Keywords: fixed1.7, regression)

Attachments

(2 files)

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: 20 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

Created:
Updated:
Size: