Page Up and Page Down don't scroll Preferences pages
Categories
(Firefox :: Settings UI, defect, P3)
Tracking
()
| Tracking | Status | |
|---|---|---|
| firefox71 | --- | affected |
People
(Reporter: erik, Unassigned)
References
Details
Go to about:preferences#general, and press Page Down. You'd expect the (long) page to scroll, but, instead, it moves to the Sync page. That's not even the next page, so it's doubly weird.
Nightly 2019-10-02, Mac
Comment 1•7 years ago
|
||
The page does scroll correctly if an element within the content area (not the sidebar or search filter) is focused.
"The page does scroll correctly if an element within the content area (not the sidebar or search filter) is focused."
Not in my experience.
Okay, it doesn't seem possible to focus anything except the painful non-scrolling sidebar or the search bar.
Comment 4•6 years ago
|
||
(In reply to MarjaE from comment #3)
Okay, it doesn't seem possible to focus anything except the painful non-scrolling sidebar or the search bar.
Bug 1364197 is for being unable to unfocus the find box by clicking outside it. The following works for me:
about:preferences→ the find box has focus- Press
Tab→ Restore previous session has focus - Press
Page Down→ scroll down the General category
about:preferences→ the find box has focus- Press
Shift+Tab×3 → General has focus - Press
Down Arrow→ change categories - Press
Tab×4 → one of the settings in the selected category has focus - Press
Page Down→ scroll down the selected category
| Reporter | ||
Comment 6•6 years ago
|
||
I would suggest that Page Down should scroll the main pane even if the Find field is focused. After all, what is Page Down going to do in a single-line field?
Comment 7•5 years ago
|
||
I am confirming this.
The only ways I can scroll the general pages is to use mouse scroll, which will show the scroll bar too. But the scroll bar disappear fast.
Click empty space in the general page doesn't help.
This is happening in both stable(88) and nightly(90.0a1)
Comment 8•4 years ago
|
||
I have same problem. All you should have to do is press any blank space submenu viewed. I don't know what 'focused' means but you shouldn't have to press elements as may not want to change anything.
Comment 9•4 years ago
|
||
I have same problem. All you should have to do is press any blank space in submenu viewed. I don't know what 'focused' means but you shouldn't have to press elements as may not want to change anything.
Users should be allowed to edit (and I hope the eight spaces at the beginning of this sentence appear, because I use traditional paragraph delimiting.)
Comment 10•4 years ago
|
||
(In reply to David Chmelik from comment #9)
I have same problem. All you should have to do is press any blank space in submenu viewed. I don't know what 'focused' means but you shouldn't have to press elements as may not want to change anything.
Focused just means the part of the page that your keyboard inputs are targeted at. Like when you click inside a textbox, that focuses it. It will usually gain a border with some highlight color like blue, signaling that you can type in it. When you open about:preferences, focus starts in the search/find bar up at the top right, and that doesn't handle PageUp/Down.
And I think on this page, the document itself and other higher level elements prevent focusing and inputs. So it won't let you navigate by keyboard without first hitting Tab to move your focus from the search bar to the first focusable element within the main content pane.
You don't actually have to click other elements, since you can just use the Tab key to focus elements without activating them. But I think it would be nice to add a way to "click out" of the search bar without needing to click an element, since that's probably a more intuitive way to lose focus than Tabbing for some users.
I imagine your normal habit is usually to just click the empty space on a page when you want to get out of a textbox? And that's what you can't do on about:preferences. I'm sure the current behavior was set that way for good reason though, since it's kinda complicated to prevent that. Not something that would happen by mistake I think. So I'll do some research on it when I get a chance and hopefully we can find a satisfying resolution.
Users should be allowed to edit
You can request the permission to edit bugs/comments, but I think you need to include links to some bugs you have worked on.
(and I hope the eight spaces at the beginning of this sentence appear, because I use traditional paragraph delimiting.)
Bugzilla uses markdown syntax, so if there's more than one whitespace character in sequence, they are collapsed down to one. So if you make a new line and the first characters on that line are 8 spaces, that's collapsed to no spaces.
If you need all your spaces to be preserved for whatever reason, like you want to indent a paragraph, type instead of hitting the spacebar. It results in something like this. So your paragraphs could be done like this:
I have same problem. All you should have to do is press any blank space in submenu viewed. I don't know what 'focused' means but you shouldn't have to press elements as may not want to change anything.
Users should be allowed to edit (and I hope the eight spaces at the beginning of this sentence appear, because I use traditional paragraph delimiting.)
Updated•4 years ago
|
Comment 11•1 year ago
|
||
This should also be under accessibility (since it makes things harder for anyone who can't use scrollbars and/or wheels).
Comment 12•1 month ago
|
||
Possible duplicate of bug 1410302.
Updated•1 month ago
|
Description
•