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.