ctrl-home and ctrl-end for jump to ends of document

VERIFIED DUPLICATE of bug 22529

Status

()

P3
normal
VERIFIED DUPLICATE of bug 22529
19 years ago
19 years ago

People

(Reporter: ve3ll, Assigned: Brade)

Tracking

Trunk
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

19 years ago
CTRL-up and CTRL-DN didnt move display to ends
of file as I had anticipated.  Many other progs
use this convention.  this may be an RFE or it
may be a bug ???

Comment 1

19 years ago
NN 4.x uses ctrl-[Home] and ctrl-[End] to jump directly to the beginning
and end of a document, respectively. 3 available text editors and IE5 do the 
same.

Mozilla 2000-03-30-09-M15 on WinNT does nothing when those key-combos are 
pressed. 

Changing summary from "ctrl up and down for fast scrolling" to
"ctrl-home and ctrl-end for jump to ends of document"

These keybindings should work when the focus is on the document, not the
scrollbars, so "XP Toolkit/Widgets" does not seem to be the right component.
Trying "Event Handling" but may be "XP Toolkit/Widgets: XBL"; looks like a 
key-event-binding issue.
Assignee: cbegle → joki
Status: UNCONFIRMED → NEW
Component: Browser-General → Event Handling
Ever confirmed: true
Keywords: 4xp
QA Contact: asadotzler → janc
Summary: ctrl up and down for fast scrolling → ctrl-home and ctrl-end for jump to ends of document
(Reporter)

Comment 2

19 years ago
along with ctl-home and ctl end for jumps to end of doc
other browsers use ctl-pg-up  and ctl-pg-dn for ONE screen
scrolls in appropriate directions... while fixes for fast
jump is being made , add for one screen scroll too  please!!

Comment 3

19 years ago
This requires another xul keybinding I guess.  Chris?  Is this yours then?
Assignee: joki → saari

Comment 4

19 years ago
Akkana, mjudge, is this easy for one of you to do? Or can someone tell me what 
needs to happen to make the document jump/scroll?
Target Milestone: --- → M16

Comment 5

19 years ago
I think we already do this for the editor, in the mac platform bindings file. 
See xpfe/global/resources/content/mac/platformEditorBindings.xul:

<!-- Mac bindings for home and end -->
<key id="macHomekb" keycode="VK_HOME" control="false" shift="false" alt="false"
   onkeypress="
     var controller =
document.commandDispatcher.getControllerForCommand('cmd_scrollTop');
     controller.doCommand('cmd_scrollTop');"/>
<key id="macEndkb" keycode="VK_END" control="false" shift="false" alt="false"
   onkeypress="
     var controller =
document.commandDispatcher.getControllerForCommand('cmd_scrollBottom');
     controller.doCommand('cmd_scrollBottom');"/>

For textareas, it's XBL.  I thought we did this for Mac, too, but looking at the
mac platformHTMLBindings.xml for textarea, I see:

      <handler type="keypress" id="key_home" keycode="VK_HOME" alt="false"
shift="false" control="false"
        command="cmd_scrollPageUp"/>
      <handler type="keypress" id="key_end" keycode="VK_END" alt="false"
shift="false" control="false"
        command="cmd_scrollPageDown"/>

Seems like those should be cmd_scrollTop and cmd_scrollBottom, but I would think
Kathy would have noticed if those had been off.  Adding her to the cc.

Anyway, adding bindings like this for shift to the global bindings (both xul and
xbl), then overriding them for Mac, if they're supposed to be something else, is
probably the right thing to do.
(Assignee)

Comment 6

19 years ago
I'll take this bug since I already have some changes to go in the keybinding 
files.  For the record, the functionality desired (scroll to top and place caret 
there), isn't yet available.  This bug needs a dependency added... I'll do that 
next week
Assignee: saari → brade
(Assignee)

Updated

19 years ago
Status: NEW → ASSIGNED

Comment 7

19 years ago
*** Bug 37813 has been marked as a duplicate of this bug. ***

Comment 8

19 years ago
I just submitted the quasi-duplicate Bug 37813 (has been marked as a duplicate 
of this bug).  It's not really a duplicate though, since I was suggesting Home 
and End, not just Ctrl-Home and Ctrl-End (which'd probably actually be Cmd-Home 
and Cmd-End on a Mac; we don't do much of anything with the Ctrl key most of the 
time). IE certainly works this way (on a Mac) as does ever single editing 
interface and almost every reading/viewing/drawing interface (from Acrobat to 
Photoshop to NCSA Telnet) I've ever used, in 8 years of Mac'ing. Even MacOS 
itself does this, in Finder windows.  I don't know about Windows users, but its 
counterintuitive and frustrating to not have functional Home & End keys in a 
browser (or anywhere else for that matter; about the only common place they 
don't work is in the license agreement windows in software installers, 99% of 
which are either Vise or Aladdin, and both of which forgot to enable End & 
Home.)

Bug 36865 has remarks about the differences between Win (positing cursor in 
address line), Linux (nothing) and Mac (top/bottom of doc.) Home/End behavior.
It's probably rational to do this differently on different platforms as per 
their default expectations.  Mac (and Linux, having no default expectation to 
the contrary) can rationally expect Home & End to work as I suggest here (and on 
Macs, neither key EVER, in my experience, has anything to do with cursor 
position in a one-line text entry box, not in apps and not in the Finder; this 
is what the arrow keys are for), while in Windows, they could have the effect 
they have now, and Windows folks can use Ctrl-Home & Ctrl-End.  I don't see any 
reason to not make those work on ALL platforms, absent a compelling reason. But 
Maccy types will definitely expect the bare Home & End keys to jump to top & 
bottom of document.

Anyway, just wanted to clarify that I'm not quite duplicating the previous 
feature requests, even though they are closely related.  And with that, I'll 
shaddap about the Home/End stuff.

PS: I've bypassed several bugs WRT making menu items have Cmd-[key] (or 
Ctrl-[key] for Win., I'm sure) shortcuts for menu items (and didn't post the 
request for Cmd-R reload that I wanted to make, figuring it'd already been 
covered. I didn't realize all this keybinding stuff was being tracked in Bug 
22529, or I wou

Comment 9

19 years ago
Quoting from bug 36865, "home/end keys do nothing",
 > ---- Additional Comments From davidr8@home.com 2000-04-23 12:48 ----
 > I don't like IE5's home/end feature, because I trigger it accidentally on 
 > long documents extremely often (while trying to pgup/pgdn).
The same could easily happen if a Win32 user thought the focus was in an
editbox and was trying to move the insertion point horizontally, but it was on 
the page. For those reasons, home and end should not be synonymous with 
ctrl-home and ctrl-end in the page focus area on Windows.

For the reasons given by mech@eff.org just above, home and end *should* jump 
to the ends of the document on Mac -- perhaps bug 37813 should be unDUP'd
to for that.

Matthew, would there be any harm in having ctrl-home and ctrl-end be synonymous
with home and end on the Mac?

Comment 10

19 years ago
No harm. The semantic value of Ctrl+Home and Ctrl+End would be to go *further* 
than the beginning/end of the document, which obviously isn't possible. So going 
to the beginning/end with Ctrl+Home/+End would be just fine. (4.x for MacOS does 
exactly nothing for either of these combinations.)

Home and End themselves should go to the start/end of the document too -- as 
mech@eff.org says, that's exactly what those keys were intended for, and if it 
causes problems with other key-bindings then it's the other key-bindings which 
need to be changed. So I'll reopen bug 36865.
OS: Windows 95 → All
Hardware: PC → All

Comment 11

19 years ago
This missing key combination is now noted in bug 22529, so marking this as a dup.


*** This bug has been marked as a duplicate of 22529 ***
Status: ASSIGNED → RESOLVED
Last Resolved: 19 years ago
Resolution: --- → DUPLICATE

Comment 12

19 years ago
verified duplicate
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.