Closed Bug 241405 Opened 20 years ago Closed 3 years ago

body scrolling problems with overflow:auto

Categories

(Core :: Web Painting, defect)

defect
Not set
major

Tracking

()

RESOLVED INCOMPLETE

People

(Reporter: simon.gilligan, Unassigned)

References

()

Details

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

This bug report is being filed after an initial discussion on mozillazine -
http://www.mozillazine.org/talkback.html?article=4650#23. Thanks Boris for your
initial comments.

The attached test case show what appears to be a regression in layout behaviour
in moz 1.7RC1. That is, the test case shows the same behaviour in IE6, moz 1.6
and moz 1.4.1, but a significantly different behaviour in 1.7RC1. The best way
to see the problem is to point IE6, moz 1.6 and moz 1.7RC1 at the test case and
observe the different renderings.

What the test case shows is an iframe with a document within.  The iframe
stretches with the browser, and so stretches and shortens the viewport through
which the iframe document is visible. The iframe document has these  CSS rules
attached to both html and body elements:

html,body  {border:0px; margin:0px; padding:0px; height:100%; }
html {background-color:whitesmoke;  border: 2px solid yellow;  -moz-box-sizing:
border-box;}
body {overflow: auto; border: 2px solid red;}
 
When the viewport is shorter than the iframe document, the iframe document scrolls. 
In moz 1.4.1, moz 1.6 and IE6:
 1. a vertical scroll bar appears.
 2. a horizontal scroll bar does not appear.
 3. the yellow html border sits at the edges of the viewport. 
 4. and red body border sits at the edges of the viewport
 5. the content scrolls without scrolling the document borders

However, in moz 1.7RC1, when the viewport is shorter than the iframe document,
this happens:
 1. a vertical scroll bar appears (ok)
 2. the yellow html border is positioned one border width too far right
(different)  
 3. a horizontal scroll bar appears (to accomodate observation 2)
 4. the yellow html border extends the full height of the document (different)
 5. the yellow and red borders scroll with the document (different)
 

So the 1.7RC1 behaviour is very different. I can't comment on correct
interpretation of W3C CSS specs - however this change in behaviour is no longer
consistent with internet explorer 6.0, and previous versions of mozilla.



Reproducible: Always
Steps to Reproduce:
go to http://level11.com.au/mozbug/shell.htm
Observation 2 boils down to the fact that we're not taking the borders properly
into account when we compute the HTML content width. We're neglecting one of the
border sides, probably the right border. That induces the horizontal scrollbar.
Definitely a bug, probably fairly easy to fix, I can probably do it for RC2.

The rest of the bug is about the fact that overflow:auto is propagated from the
IFRAME's BODY to the IFRAME's viewport. Apparently IE does not do this. But IE
does propagate a root document's overflow:auto on BODY to the viewport, I think
(can someone confirm? I don't have IE here). So IE is being inconsistent by
treating IFRAMEs and root documents differently. We definitely want to treat
them consistently.

(I believe that propagating overflow:scroll and overflow:auto from BODY to the
viewport actually made us MORE IE compatible for root documents, but again it
would be nice if someone could confirm that.)

Pre-1.7 we propagated overflow:hidden from BODY to the viewport for Web
compatibility, but not scroll or auto. That's also somewhat inconsistent and we
don't want to keep doing that.

So for reasonable consistency we want to either always propagate BODY overflow
to the viewport (assuming it's not 'visible' and we didn't already propagate
something from the HTML element), or never propagate BODY overflow to the
viewport. Either would be permissible by CSS2.1. But the latter option would
break Web sites that rely on BODY overflow:hidden disabling scrolling in the
viewport. So I think we're stuck with the current 1.7RC1 propagation behaviour.

It's unfortunate that it breaks existing sites, and I really do care about that,
and we try hard to avoid it, but we have to be able to fix bugs otherwise you
end up with the IE situation where lots of functionality is weird and broken and
can never be fixed.

A workaround that should work in 1.7, pre-1.7, and IE6 is to make the HTML
element overflow:hidden. That will stop the BODY overflow from propagating.
Indeed, that fixes the problem in Mozilla 1.7b (and therefore 1.6 and earlier)
and 1.7RC1.
(In reply to comment #2)
> Indeed, that fixes the problem in Mozilla 1.7b (and therefore 1.6 and earlier)
> and 1.7RC1.

Many thanks Robert for your explanation and suggested workaround. I have applied
this workaround here - http://level11.com.au/mozfix/shell.htm if anyone is
interested (works IE6, moz 1.7RC1, moz 1.6).

ok - my UIs might be broken without the workaround (I had a bit of whine about
this on mozillazine - sorry I should have waited for an outcome) but the fix is
truly simple and clean. This makes me happy!

Again - many thanks, I am happy for this report to go where-ever it may from now
(be it closed, or focused to dealing with the horizontal scrollbar).

Do I need to do anything with this?

Cheers,
Simon.


Please file a new bug assigned to me about the horizontal scrollbar issue. If
you can, it would be easier to fix if you had a testcase that uses DIVs rather
than an IFRAME (although the bug may depend on the IFRAME).

Thanks!!
roc: Are we currently consistent in quirks vs standards? Should we just do the
IE-like wacky behaviour in quirks, and be completely consistent (e.g. only do it
on the root element, but always do it on the root element) in standards?
Ian, I know Mozilla is not a HTML UA, but there are quite some developers/sites,
who depend on this rule from CSS 2.1 [1].

<http://www.w3.org/TR/CSS21/visufx.html#overflow>
> HTML UAs may apply the overflow property from the BODY or HTML elements to 
> the viewport.
Ian: none of this depends on the quirks setting.

I'd be willing to look at specific proposals for a quirks-based policy, but I
don't see a pressing need for it. And once 1.7 has shipped I'd be against
changing behaviour again.
I'd say stick with what we do now, then. It seems consistent with itself and
with the spec. If IE compatibility is a requirement, though, I'd do that in
quirks mode (and of course would remove another quirk first!).
(In reply to comment #4)
> Please file a new bug assigned to me about the horizontal scrollbar issue. If
> you can, it would be easier to fix if you had a testcase that uses DIVs rather
> than an IFRAME (although the bug may depend on the IFRAME).

I've created a new bug report for this:
http://bugzilla.mozilla.org/show_bug.cgi?id=241694

I was unable to re-create the problem using purely divs (I think the issue is
with the HTML element), but I was able to drop the iframe and show the
horizontal scrollbar on a single page.

Cheers,
Simon.


Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.8b4) Gecko/20050906
Firefox/1.4 ID:2005090605

This behavior persists in the above nightly.  Without comment to the accuracy of
display (i.e., this may not be a bug), I am marking this bug CONFIRMED and
moving to Core/Layout: View Rendering.
Assignee: nobody → roc
Status: UNCONFIRMED → NEW
Component: Layout → Layout: View Rendering
Ever confirmed: true
QA Contact: layout → ian
QA Contact: ian → layout.view-rendering
The testcase URL is no more available.
Is there any way to reproduce this bug?
Component: Layout: View Rendering → Layout: Web Painting

Closing this issue as resolved:incomplete since the testcase URL is no longer available and there were no updates made on this issue in the last 12 years.

Status: NEW → RESOLVED
Closed: 3 years ago
Resolution: --- → INCOMPLETE
You need to log in before you can comment on or make changes to this bug.