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.

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.

(Not yet sure about the component.)