Closed Bug 547019 Opened 14 years ago Closed 14 years ago

BODY overflow:hidden possibly not fully respected

Categories

(Core :: Layout, defect)

1.9.2 Branch
x86
Windows XP
defect
Not set
normal

Tracking

()

RESOLVED DUPLICATE of bug 295020

People

(Reporter: avih, Unassigned)

References

()

Details

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2) Gecko/20100115 Firefox/3.6
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2) Gecko/20100115 Firefox/3.6

On some cases BODY with overflow:hidden can be scrolled using Autoscroll or keyboard (either arrows or PgUp/PgDn). This breaks some scroll functionality on pages which rely on body overflow:hidden not allowing scroll. It also looks weird because an element with no scrollbars gets scrolled (e.g.: the home page of the biggest news site in Israel: http://ynet.co.il ).

Reproducible: Always

Steps to Reproduce:
1. Load http://smoothwheel.mozdev.org/test_cases/body_overflow_hidden.php (or http://ynet.co.il - a much more complex page)
2. Use Autoscroll to scroll down, or, Without clicking on the page*, press Page-Down or the down arrow.

Actual Results:  
Document's BODY is scrolled.

Expected Results:  
1. Body doesn't scroll.
2. Preferably also: the scrollable node which fills the window get scrolled.

CSS 2.1 spec states that elements with overflow:hidden should not provide UI for scrolling by the UA ( http://www.w3.org/TR/CSS2/visufx.html#propdef-overflow ). While autoscroll and keyboard are not in-page scroll widgets, they are still very much user-interfaces, and as such, should also not scroll such elements.

The CSS spec also states that on some cases, the overflow property of a root element should be propagated to the viewport. I'm not sure I fully understand these cases, but after reading bug #241405 (status: NEW since 2004!) it seems that body overflow:hidden should be respected and not scrollable.

Possibly related: The actual reason for autoscroll or keyboard "failing" to respect the absence of scrollbars might be related to the fact that #document.defaultView.scrollBars.visible==true AND scrollMaxY>0, and without the scroll targeting a specific inner node of the page, it tries to scroll document.defaultView.

As a more general note, I think that for consistent behavior and for better exposing of scrollability, a node which is scrollable (by the UA) using keyboard or autoscroll or mouse wheel, must also provide visible scroll bars. This prevents unexpected scroll of a node which is apparently non-scrollable (by the UA).

- Screenshots of ynet.co.il home page after and before using autoscroll:
http://i46.tinypic.com/v621vo.png

- This bug probably applies to all OSs and platforms, but only tested on XP/X86.


* If the page is clicked before trying keyboard scroll, it usually scrolls OK, probably due to event.target being a more inner node which is contained in a scrollable node. Autoscroll still gives unexpected results though.
Version: unspecified → 3.6 Branch
Also, FWIW, IE8 behaves as expected: doesn't scroll BODY, and does scroll the scrollable node which fills the window, using either KB or autoscroll.
Component: General → Layout: View Rendering
Product: Firefox → Core
QA Contact: general → layout.view-rendering
Version: 3.6 Branch → 1.9.2 Branch
(Not yet sure about the component.)
Component: Layout: View Rendering → Layout
QA Contact: layout.view-rendering → layout
Status: UNCONFIRMED → RESOLVED
Closed: 14 years ago
Resolution: --- → DUPLICATE
You need to log in before you can comment on or make changes to this bug.