143996 - in caret browsing, home/end must go to start/end of line

Status: RESOLVED FIXED

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

Description

[dmitry]

in caret browsing, home/end must go to start/end of a line and not to start/end
of the page as they do now.

Comment 1

[Boris Zbarsky [:bzbarsky]]

keyboard nav

Comment 2

[Kyle Yuan]

aaron, any idea? is that a feature?

Comment 3

[Aaron Leventhal]

It makes sense for the key bindings to act as they do in Composer.

So Home/End should go to beginning/end of line.
Ctrl+Home/End should go to beginning/end of document.

Comment 4

[Joseph Tate]

And shift-ctrl-home/end should select from the position to the begining/end of
the web page.

Comment 5

[Aaron Leventhal]

*** Bug 205644 has been marked as a duplicate of this bug. ***

Comment 6

[Peter Englmaier]

When I view a page like this: http://de.biz.yahoo.com/179/
and caret browsing is turned on, then pgup/pgdn do not work as expected. Pgup/Pgdn
cannot reach the beginning and end of the document. I just tried the
new alpha release Mozilla 1.5a Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5a)
Gecko/20030718 on redhat linux 8.0 with gnome.

Comment 7

[Aaron Leventhal]

(In reply to comment #6)
> When I view a page like this: http://de.biz.yahoo.com/179/
> and caret browsing is turned on, then pgup/pgdn do not work as expected. Pgup/Pgdn
> cannot reach the beginning and end of the document. I just tried the
> new alpha release Mozilla 1.5a Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5a)
> Gecko/20030718 on redhat linux 8.0 with gnome.
> 

That's a different bug, file it separately if you wish. It's blocking the meta
bug 241023.

Comment 8

[Rick Ju]

Attachment: home/end for line and ctrl-home/end for page

Comment 9

[Kathleen :Brade]

Comment on attachment 158288 [details] [diff] [review]
home/end for line and ctrl-home/end for page

This patch is on the right track.  However, it changes the behaviors on all
platforms and that is wrong.  Mac behavior is the current behavior (no change
to caret when pressing home/end).

Also, I'd guess that you should be using "accel" instead of "control" since the
accelerator key is configurable via prefs.

Comment 10

[Ginn Chen]

(In reply to comment #9)
> (From update of attachment 158288 [details] [diff] [review])
> This patch is on the right track.  However, it changes the behaviors on all
> platforms and that is wrong.  Mac behavior is the current behavior (no change
> to caret when pressing home/end).
In Mac, Option+left/right move a word, Command+left/right move to beginning/end 
of line, Home/End move to top/bottom of document.
Is it right?

Comment 11

[Rick Ju]

so we should only change platformHTMLBindings.xml in unix and win?

Comment 12

[Kathleen :Brade]

I'm not sure if the previous comments were addressed to me or anyone in
particular.  I'll answer them with my opinions; in the future please include the
name or e-mail address for the people you are addressing (e-mail doesn't present
the entire thread only a snippet and I often delete comments which don't include
my name/e-mail).

Ginn Chen (comment 10) -- yes, "Home" and "End" scroll to the top (the caret /
insertion point is not moved)

Rick Ju (comment 11) -- you'll probably need to move the generic one to the
Macintosh-specific file and create new ones for Windows (and Linux?).  I'd
expect to see a diff which touched at least 4 files (do we care about OS2 and
some other OS?)

Comment 13

[Ginn Chen]

Attachment: patch v2

new patch

on mac, the behaviour with text in mozilla is very different to Microsoft Word.

So I don't know how to do with mac. just keep no change.

Comment 14

[Kathleen :Brade]

Comment on attachment 169487 [details] [diff] [review]
patch v2

r=brade with some whitespace cleanup.

in mac/platformHTMLBindings.xml, you removed a blank line.  Please add the
blank line back.  The scrollTop/scrollBottom handlers you add should be in the
first block (after VK_PAGE_DOWN) not in the 2nd block.

in unix/platformHTMLBindings.xml, I would probably add a blank line before all
of the function key handlers (after the last VK_END keypress handler).

I'd also add a blank line after the last VK_END key handler in
win/platformHTMLBindings.xml (although they aren't completely in order with
some of the home/end bindings at the bottom of the diff and some in the middle
<sigh>)

p.s. please add a new patch of what you are about to checkin in case it is
needed at a later date.

Comment 15

[Ginn Chen]

Attachment: patch v2 (whitespace cleanup)

Comment 16

[Kathleen :Brade]

Comment on attachment 169886 [details] [diff] [review]
patch v2 (whitespace cleanup)

r=brade (assuming it has been tested on all platforms)

Thanks!

Comment 17

[Ginn Chen]

Checking in browser-base.inc;
/cvsroot/mozilla/content/xbl/builtin/browser-base.inc,v  <--  browser-base.inc
new revision: 1.2; previous revision: 1.1
done
Checking in gtk2/platformHTMLBindings.xml;
/cvsroot/mozilla/content/xbl/builtin/gtk2/platformHTMLBindings.xml,v  <-- 
platformHTMLBindings.xml
new revision: 1.3; previous revision: 1.2
done
Checking in mac/platformHTMLBindings.xml;
/cvsroot/mozilla/content/xbl/builtin/mac/platformHTMLBindings.xml,v  <-- 
platformHTMLBindings.xml
new revision: 1.16; previous revision: 1.15
done
Checking in unix/platformHTMLBindings.xml;
/cvsroot/mozilla/content/xbl/builtin/unix/platformHTMLBindings.xml,v  <-- 
platformHTMLBindings.xml
new revision: 1.21; previous revision: 1.20
done
Checking in win/platformHTMLBindings.xml;
/cvsroot/mozilla/content/xbl/builtin/win/platformHTMLBindings.xml,v  <-- 
platformHTMLBindings.xml
new revision: 1.23; previous revision: 1.22
done