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 ???
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
QA Contact: asadotzler → janc
Summary: ctrl up and down for fast scrolling → ctrl-home and ctrl-end for jump to ends of document
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!!
This requires another xul keybinding I guess. Chris? Is this yours then?
Assignee: joki → saari
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
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.
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
*** Bug 37813 has been marked as a duplicate of this bug. ***
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
Quoting from bug 36865, "home/end keys do nothing", > ---- Additional Comments From email@example.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 firstname.lastname@example.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?
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 email@example.com 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
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
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.