With overflow:hidden on the viewport, you should not be able to scroll with the keyboard
Categories
(Core :: Layout, defect)
Tracking
()
People
(Reporter: martijn.martijn, Unassigned)
References
()
Details
(Keywords: testcase, Whiteboard: DUPEME)
Attachments
(2 files)
|
368 bytes,
text/html
|
Details | |
|
901 bytes,
patch
|
Details | Diff | Splinter Review |
Bug 259615 is fixed, but I can still scroll the page when the root element has overflow:hidden. See upcoming testcase. You should also not be able to scroll with the keyboard in this case (not with arrowkeys/spacebar/pageup/pagedown.
|
Reporter | |
Comment 1•19 years ago
|
||
|
||
Updated•19 years ago
|
I believe I have the same problem, checkout www.allstudentrentals.com, wait for the page to load then hit down on your keyboard. Are you using Adobe Flex?
|
||
Comment 4•16 years ago
|
||
This isn't plugin related. See the testcase which is simple html/css. When I looked at the site you gave I saw the overflow was set to hidden on the body using the DOM inspector. I'm not sure which bug Boris had in mind when adding DUPEME. Perhaps that would be Bug 259615 but since that's fixed perhaps that should be Bug 325942 instead? Or this bug doesn't need duping now.
does anyone have any solutions to this issue? Why does this only happen in Firefox and not IE or Chrome? I am new to Bugzilla, how do I get this error fixed? My website, www.allstudentrentals.com has the majority of Firefox hits and this bug is annoying to users
|
|
Reporter | |
Comment 6•16 years ago
|
||
Just use:
window.onkeydown = function(e) {
e.preventDefault();
}
as a workaround for this bug.
|
||
Updated•15 years ago
|
|
||
Comment 11•14 years ago
|
||
This is not yet fully tested.
|
|
||
Comment 12•14 years ago
|
||
The patch breaks keyboard scrolling on http://quality.mozilla.org/get-involved
|
||
Comment 15•11 years ago
|
||
Have stumbled across this bug as well while designing a page layout with a fixed footer, which depends on the body's height being exactly the viewport's height. This layout breaks if the page contents become too large for the viewport even with overflow: hidden set on the body. This has nothing to do with preventing any keyboard navigation, so the workaround suggested above in Comment 6 is not really one.
|
||
Comment 16•10 years ago
|
||
I can confirm this bug exists in FF27.
overflow:-moz-hidden-unscrollable; will do no effect without max-heigt:100%; that will breaks scroll position
Also want to add quote from css3-box model about overflow:hidden
hidden
This value indicates that the content is clipped and that no scrolling mechanism should be provided to view the content outside the clipping region.
Current used solution for me is to reset scroll positions on window.onscroll event.
|
||
Comment 17•10 years ago
|
||
I can confirm that this bug still exists in FF29. I'm creating a coverflow-like effect and the photos that are partly outside the viewport allow the arrow keys to scroll laterally.
|
||
Comment 18•10 years ago
|
||
I can confirm that this bug still exists in FF30.0. Using a carousel library (flexslider) with a range of floating (inline) images, and overflow-x: hidden set on <body>, no scrollbar is shown but the arrow keys do trigger horizontal scrolling.
|
|
Reporter | |
Updated•7 years ago
|
|
|
||
Updated•7 years ago
|
|
||
Updated•2 years ago
|
|
||
Comment 22•2 years ago
|
||
The severity field for this bug is relatively low, S3. However, the bug has 10 duplicates.
:dholbert, could you consider increasing the bug severity?
For more information, please visit auto_nag documentation.
|
||
Comment 23•2 years ago
|
||
The last needinfo from me was triggered in error by recent activity on the bug. I'm clearing the needinfo since this is a very old bug and I don't know if it's still relevant.
|
||
Comment 24•2 years ago
|
||
Pretty sure we fixed this years back. Please re-open if I'm mistaken.
|
||
Comment 25•2 years ago
|
||
Yeah, this seems to be worksforme.
mozregression --find-fix gives me this fix-range:
https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=b4c1ad9565ee9d00d96501c4a83083daf25c1413&tochange=ea7b55d65d76214f97aaae502d65cb26fc6f5659
In that range, I suspect bug 1369072 to be the thing that fixed it -- that bug was mostly about selection but dealt with scrollability as well. e.g. this commit seems relevant:
https://hg.mozilla.org/mozilla-central/rev/19f8a5d3da39cc4f2313f2dac2c4dbb04a6329e8
Bug 1369072 - part1: PresShell should climb up scrollable frames when there is no selection, no focused content and root scrollable frame isn't scrollable
Description
•