Open Bug 108522 Opened 23 years ago Updated 2 years ago

Horizontal scrolling with the keyboard

Categories

(Core :: DOM: UI Events & Focus Handling, enhancement, P3)

Product:
Core
Component:
DOM: UI Events & Focus Handling
Type:
enhancement

Tracking

()

People

(Reporter: u37792, Unassigned)

References

(
URL
)

Details

From Bugzilla Helper: User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.5) Gecko/20011011 BuildID: 2001101117 There are many pages which are too wide, and since home and end go to the top-left and bottom-left corners respectively, browsing these pages is a pain in the rear. An option to either force text to fit in the window, or change home and end keys to behave like home = left edge, home,home=top-left (and the opposite for end) is needed. Reproducible: Always Steps to Reproduce: 1.Go to http://tcl.activestate.com:8002/resource/doc/manual/ 2.Scroll sideways using 3.Try to get back to the left edge in one keystroke, or using the mouse wheel. I imagine this could be worked around using middle-button to move the page instead of middle-button to open links in a new window, but I greatly prefer the latter behavior, and not everyone has a three-button mouse.
So I take it that you held down the right arrow key for a few secconds, and found that frustratingly long? I'm not clear from your description on what you'd like home and end to do. Would it be like this? Home once - beginning of line Home twice - beginning of document and line End once - end of line End twice - end of document and line I wouldn't advocate that solution since people are used to home and end bringing them to the top and bottom of the doc with 1 key press. Maybe you were saying something else?
I'd say you've got the jist of it. I was thinking of WP 5.1 if anybody remembers that. It's just a bitch with certain pages to have to wait to scroll (mostly automatic man-pages). I know many people are used to the home takes you to the same point in the document no matter what, which is why this should be configurable in user.js. And unless I set the keyboard to repeat almost immediately, it is a frustratingly long wait. Mayhaps, ctrl-home could be go to edge, not corner and likewise for ctrl-end (although Bug 70154 already requests these keys act just like home/end without modifiers).
I agree that Ctrl+Home and Ctrl+End should go to the true beginning/end of the document. This in fact does not conflict with bug 70154, which is about Ctrl+shift+home and Ctrl+shift+end selecting to the beginning or end of document. It's perfectly in sync with that plan. Changing summary, marking NEW
Status: UNCONFIRMED → NEW
Ever confirmed: true
Summary: Need option to force page width to window width (text wrap-around) or change home/end behavior → Ctrl+home and Ctrl+End to go to top left and bottom right of document
Status: NEW → ASSIGNED
Home and End currently go to the top-left corner and the bottom-left corner. I End should be changed to go to the bottom-right corner.
Jesse, I was more thinking this would navigate to the top-left/bottom-right most link or form control.
Summary: Ctrl+home and Ctrl+End to go to top left and bottom right of document → Ctrl+home and Ctrl+End to go to top left and bottom right focusable item in document
Please view bug 163562 for additional comments
Aaron: I think more users expect Ctrl+Home/Ctrl+End to scroll all the way to the beginning/end of the document than expect them to focus anything. If they were to focus a textarea, it would be impossible to continue scrolling using the keyboard.
Jesse, true - but that's what Home and End are for. Right now there's no good way to jump to the first or last focusable item in a document.
ctrl-l, tab, tab ctrl-l, shift-tab wfm i'd prefer to be able to use [ctrl-]home/end to go to top/bottom and right/left edges.
Timeless, not true - that doesn't work. We do what IE does. After you tab out of the location bar, you first tab to the doc as a whole, then the next tab goes back to where you were in the document. The user doesn't lose their place. Maybe we should reset the position on Accel+L, but it could be argued that retaining the postion is useful.
OS: Windows 2000 → All
If there are no focusable items in the doc, where should it go then? Edges or corners? Nowhere?
In most Windows apps, Ctrl+Home and Ctrl+End scroll to the beginning and end of the document. Focusing the first/last item in the document instead would break our consistency with other apps, and would sometimes make it impossible to continue scrolling after using Ctrl+Home or Ctrl+End, depending on what type of element gets focus.
So the sensible plan people seems to be: Caret browsing off: Home, End scroll to top/bottom without changing horizontal position. Ctrl+Home, Ctrl+End scroll horizontally to beginning or end without changing vertical position Caret browsing on: Home, end move caret to beginning/end of line as it does now Ctrl+Home, Ctrl+End move caret to very beginning or end of doc Either: Ctrl+Shift+Home, Ctrl+Shift+End Select to beginning/end of doc Agreements? Disagreements?
Priority: -- → P3
Summary: Ctrl+home and Ctrl+End to go to top left and bottom right focusable item in document → Horizontal scrolling with the keyboard
I disagree with Caret Browsing off, Ctrl+Home, Ctrl+End scroll horizontally to beginning or end without changing vertical position. Ctrl+Home, Ctrl+End should be as same as Home/End with Caret Browsing off.
(In reply to comment #14) Ginn, what is your suggestion for keys to scroll horizontally? These are not needed in caret browse mode, since scrolling horizontally is possible by moving the caret.
What about Ctrl+Shift+Left/Right scroll horizontally to beginning or end without changing vertical position, Ctrl+Left/Right scroll one page horizontally ? Agree, we don't need scroll while caret browsing.
Shift plus arrow keys should always change the selection. That's what it does in every modern app and it's one of the basic things people expect. Why should Home/End be duplicated with Ctrl+Home/End? Side Note: URL is invalid now and I can't find any other examples of really wide pages. The only cases for horizontal scrolling seem now to be users with low res screens or big images.
Agreed, shifted directional commands are always for selection.
Hardware: PC → All
(In reply to comment #17) > Shift plus arrow keys should always change the selection. That's what it does > in every modern app and it's one of the basic things people expect. OK, I agree > Why should Home/End be duplicated with Ctrl+Home/End? In most app, Ctrl+Home/End goes to beginning/end of document. > > > Side Note: URL is invalid now and I can't find any other examples of really wide > pages. The only cases for horizontal scrolling seem now to be users with low > res screens or big images. > Try http://www.smallstoriesonline.com/Comics/10Commandments/10Commandments.htm From comment #3 of bug 273020
Mass un-assigning bugs assigned to Aaron.
Assignee: aaronleventhal → nobody
QA Contact: bugzilla → keyboard.navigation
This is a mass change. Every comment has "assigned-to-new" in it. I didn't look through the bugs, so I'm sorry if I change a bug which shouldn't be changed. But I guess these bugs are just bugs that were once assigned and people forgot to change the Status back when unassigning.
Status: ASSIGNED → NEW
I just created an account in here in order to promote this bug. Current default action is going back and forward in history, which also can be done easily with alt + <> heys. While this can be disabled, it cannot be turned into something useful today. I consider scrolling horizonally would be awesome. You could make a new value for those "mousewheel.horizscroll.*" options in about:config, and maybe make this new value the default one. Other software that uses this combination to scroll horizontally: gnome image viewer (eog): simple mousewheel zooms in and out, Ctrl + mousewheel scrolls vertically, Shift + mousewheel scrolls horizontally The GIMP, Inkscape: simple mousewheel scrolls vertically, Ctrl + mousewheel zooms in and out, Shift + mousewheel scrolls horizontally evince, openoffice, maybe others too: simple mousewheel scrolls vertically, Shift + mousewheel scrolls horizontally It totally looks like an industry-standard shortcut to me. Thanks! (un)Related note: I recently filled a similar bug in Midori browser bts: http://www.twotoasts.de/bugs/index.php?do=details&task_id=735 Feel free to be the first browser in implementing it!
Safari has implemented this for quite a while, at least on OS X 10.5 and 10.6. The key combo used is option + left / right arrow.
Thanks to your comment, i just realized that midori does that with just left/right arrow :O
Component: Keyboard: Navigation → User events and focus handling
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.