163562 - home/end keys should not affect horizontal scrolling

Status: RESOLVED FIXED

(Core :: DOM: UI Events & Focus Handling, defect)

Description

[dmitry]

1. open any page
2. resize the window so that a horizontal scrollbar appears
3. scroll to the right
4. press end or home

Actual result: page scrolls to the bottom (for end) or top (for home) but also
scrolls horizontally back to the left. 

Required result: only vertical scrolling

Rationale: pgup/pgdn and up/down arrow keys do not scroll horizontally; the
meaning of the end key is, loosely, "repeat pgdn to the end of page", so
horizontal scrolling is irrelevant. Also, MSIE in the same situation does not do
horizontal scrolling.

Comment 1

[Niklas Dougherty]

I think "home" is a metaphor for "go to the origin", i.e. (0,0), the upper left
corner (or wherever the text starts). Similarly, "end" would (or should) mean
wherever the last byte of test is geographically located on the canvas.

At least the "home" function is established in most apps.

Comment 2

[dmitry]

if home means going to coordinates (0,0), then logically, end must go to
coordinates (max,max), i.e. to the bottom right corner - scrolling all the way
to the right if horizontal scrollbar is enabled.

However, a pair of keys for doing only vertical scrolling to the maximum is
still needed. For example if I'm viewing a rightmost column in a wide table that
takes a whole page, I want to be able to go to the top/bottom of the table
without losing view of my column.

So, what about ctrl-home and ctrl-end? They jump to beginning/end of text in a
text box, so it is only logical to have them do the same in the browser window
(even if with a minor difference related to horizontal scrolling). Or
alternatively, ctrl-home/end can do vertical home/end with horizontal scrolling
but home/end alone, without. 

Also, bug 143966 suggests that home/end in caret browsing must work as in an
editor, by going to start/end of the current line. Therefore, enabling
ctrl-home/end will have the additional advantage of providing consistently the
same function everywhere - in edit boxes, in caret browsing, and in normal
browsing. Looks like this has been proposed before (bug 108522, bug 161923).

To summarize my points: 

1. make end go to the bottom right corner, not bottom left (mentioned in bug 108522)

2. enable ctrl-home/end go to beginning/end of page (bug 108522), but

3. allow only vertical scrolling by ctrl-home/end, not horizontal (new for this
bug).

Comment 3

[dmitry]

sorry, it's bug 143996, not 143966

Comment 4

[Niklas Dougherty]

Shift + arrow up/down seems to achieve vertical-only home/end, at least on Mac OS X.

Comment 5

[dmitry]

In both Windows and Linux, shift-up or shift-down work exactly like home and
end, i.e. WITH horizontal scrolling. However I don't think that these keys are a
good idea in any case, because their meaning in the browser is thus different
from that in a text box or caret browsing. Ctrl-home/end would be more consistent.

Comment 6

[Benjamin Smedberg]

->Keyboard navigation ->NEW

What about when there is only a horizontal scroll bar?  In this case HOME and
END ought to scroll horizontally.  It is my opinion that HOME at least ought to
take me back to 0,0.  Any Shift-combination ought to be reserved for text
selection (shift-up and down now do text selection even outside of editor).  Why
not use Crtl-Pageup/Pagedown to go to the top and bottom without changing
horizontal position?

Comment 7

[dmitry]

To make home/end useful in horizontal-scroll-only situations:

home must go to (0,0), as now;  
end  must go to (max,max), NOT (0,max) as now.

I agree that shift-arrows are not the best place to add a new movement semantics
because they are reserved for the "same movement but with selection" semantics.

As for ctrl-pgup/ctrl-pgdn for vertical-only scroll, I would not object, except
that I think ctrl-home/ctrl-end are a more logical choice for this.

Comment 8

[Aaron Leventhal]

I can't take this any time soon -- working on too many other things.

Comment 9

[dave bordoley]

The typical spec we use in gnome is that home and end scroll vertically to the
top and bottom of a document respectively.

Ctrl+Pgup/dwn should scroll horizontally.

Comment 10

[Lewis Jardine]

FWIW, in IE 6 'home' and 'end' move to (current,0), and (current, max) respectively.

In my opinion, scrolling two axis at one is an unusual thing to do - all the
apps I've looked at (notepad, word, explorer, IE) scroll only in one direction. 

A possible solution would be to have home/end go min/max vertically in the case
that the windows is scrollable vertically (whether or not it is also scrollable
horizontally), and to scroll horizontally in the case that the window is /only/
scrollable horizontally. 

In the case where the window is scrollable vertically and horizontally, ctrl
(accel?)-[home|end] could scroll horizontally.

Rationale:
In most cases, home/end should scroll vertically - this is the expected
behaviour now, as this is what so many other web browsers do.

In the horizontal only case, the home/end would otherwise go unused. It is
reasonable to assume that if the user were to press home/end, he would be
expecting it to scroll horizontally.

ctrl-home/ctrl-end is commonly used to rotate the axis of scrolling through 90
degrees - every editor and text-box control I've seen does this. It is likely
that ctrl-home/ctrl-end is a shortcut the user might try after finding that
home/end scrolls vertically, not horizontally.

Comment 11

[Christian Adam]

Attachment: patch to make home/end key scroll only vertical

Hi,

I have never submitted a bug before, so I hope I did everything right. This
Patch should fix the Problem with scrolling using the home/end keys.
Actually I just changed one line of code in nsScrollPortView::ScrollByWhole
(located in view/src - line 461). The ScrollByWhole-method is called by
nsEventStateManager::PostHandleEvent (content/events/src - line 2110) to change
the scrolling position.
In ScrollByWhole I replaced 0 for the x-coordinate with the member variable
"mOffsetX" containing the current horizontal Position.

I would be glad if someone could do a review on this. Thanks.


Christian Adam
[e-mail]

Comment 12

[Aaron Leventhal]

Comment on attachment 166324 [details] [diff] [review]
patch to make home/end key scroll only vertical

The only think you forgot to do is flag your patch for review :)
Looks like a nice solution.

Click to edit the patch and set the super review flag to ? and type o'callahan
in the requestee field.

Comment 13

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Comment on attachment 166324 [details] [diff] [review]
patch to make home/end key scroll only vertical

Great stuff!

Aaron can check this in for you when the tree opens.

Comment 14

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Thanks a lot for the patch, by the way.

Comment 15

[Aaron Leventhal]

Oops, checkin comment should have said patch by Christian Adam. Sorry. Thanks
for the fix.

Checking in nsScrollPortView.cpp;
/cvsroot/mozilla/view/src/nsScrollPortView.cpp,v  <--  nsScrollPortView.cpp
new revision: 3.70; previous revision: 3.69
done

Comment 16

[Christian Adam]

Thanks for checking in and everything! Submitting bugfixes seemed pretty easy
... I could get used to that :-)