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

RESOLVED FIXED

Status

()

Core
Layout: View Rendering
--
major
RESOLVED FIXED
14 years ago
12 years ago

People

(Reporter: Jeroen Asselman, Assigned: roc)

Tracking

({fixed1.7, regression})

Trunk
fixed1.7, regression
Points:
---
Bug Flags:
blocking1.7 +

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(2 attachments)

(Reporter)

Description

14 years ago
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;

Comment 1

14 years ago
What W3C recommandations say about the scrollbar?

Comment 2

14 years ago
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.
Created attachment 146791 [details]
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?
Yeah, this regressed on the branch between 2004-04-13-10 and 2004-04-14-10,
which limits us to:

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=explicit&mindate=2004-04-13+10%3A00%3A00&maxdate=2004-04-14+10%3A00%3A00&cvsroot=%2Fcvsroot

Still a number of checkins in there... and bug 234851 is still the most likely
culprit.
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.

Updated

14 years ago
Summary: div overflow: hidden position: fixed shows scrollbar with a containting div → div overflow: hidden position: fixed shows scrollbar with a containing div
Created attachment 146800 [details] [diff] [review]
Roc's proposed fix

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.
Attachment #146800 - Flags: approval1.7? → approval1.7+
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
Last Resolved: 14 years ago
Keywords: fixed1.7
Resolution: --- → FIXED
*** Bug 242660 has been marked as a duplicate of this bug. ***
You need to log in before you can comment on or make changes to this bug.