When a textarea has focus and more text in the area than can be displayed at once, standard behavior on Windows is for page up and page down (or PgUp and PgDn) to scroll the textarea up and down by the visible amount of text and to reposition the cursor. It scrolls the same amount as is scrolled by clicking the scrollbar on the scroll "background" instead of on the thumb. This impacts keyboard access to long text fields. When clicking PgUp and PgDn, Mozilla does not scroll the textarea at all. Note that this is not a duplicate of bug 27771. 27771 deals with text fields (as in input type=text) and not textareas. Observed with Mozilla/5.0 (Windows; U; WinNT4.0; en-US; m18) Gecko/20010105.
Added 4xp and correctness keywords. I also added access since this is standard keyboard behavior for scrolling in input boxes (and it works with selection boxes--just try clicking in the cc list and use PgUp/Dn). I should also mention that you can observe this bug by clicking the URL above, then clicking in a text area and then trying to use the PgUp and PgDn keys to navigate through the text area. In NS4/IE5 you'll be able to scroll. Mozilla won't.
Keywords: 4xp, access, correctness
Reassigning QA Contact for all open and unverified bugs previously under Lorca's care to Gerardo as per phone conversation this morning.
QA Contact: lorca → gerardok
Status: NEW → ASSIGNED
Target Milestone: --- → mozilla0.9
Well after some looking into this it doesn't look like the nsISelectionController interface has an api for paging up and down inside a multiline text field. Or am I missing it. In any case the code is calling the standard pageup/down call, which then doesn't scroll the page, probably due to bug 27771. I think nsISelectionController probably needs a pageup/down methods on the interface and the keys should be linked to them for textareas. I'm thinking this is less an event bug than a editor control bug which is anthonyd's field these days. Currently slated for 0.9 but I'll let anthonyd prioritize it for his own bug list.
Assignee: joki → anthonyd
Status: ASSIGNED → NEW
well, this does to apeear relatively easy: add some emthods to the nsSelectionController interface tie the pgup pgdn keys in to text area ill keep it on 0.9 anthonyd
Status: NEW → ASSIGNED
Priority: -- → P3
I believe that the API is present: for Mac users, there is scrollPage for Windows and Linux users, there is pageMove (p.s. Is it too late to make this api more consistent to always have the verb first?) This bug is probably simply a keybinding issue and may even be fixed by work Akkana and I already have in our trees. Tony--feel free to reassign to Akkana or me for keybinding issue.
I don't think it's just keybindings. I tried putting: <handler event="keypress" keycode="VK_PAGE_UP" command="cmd_movePageUp"/> <handler event="keypress" keycode="VK_PAGE_DOWN" command="cmd_movePageDown"/> in platformHTMLBindings.xml, and page up/down still didn't work. I tried using cmd_scrollPageUp/Down instead of move (in case the move commands weren't working right), and it didn't help. I also tried using keydown instead of keypress, no dice. Something else is wrong with these commands.
I see it on Linux too, please make OS->All.
Joki told me Friday that he'd traced this in the debugger and it was ending up in the page up/down code for the pres shell, rather than the one for the text control. He thought he'd mentioned that in the bug, but I don't see it here. BTW, I agree with Kathy that it would be nice if we could rename pageMove to be movePage consistent with scrollPage. Since I don't think pageMove has actually done anything useful up to now (or is it scrollPage that hasn't?), maybe it's not too late to rename one combination or the other.
OS: Windows NT → All
Hardware: PC → All
moving to mozilla0.9.1
Target Milestone: mozilla0.9 → mozilla0.9.1
*** Bug 75343 has been marked as a duplicate of this bug. ***
Kathy just discovered that a bunch of navigation methods in nsGfxTextControlFrame2.cpp are defined to do nothing, including the page up/down comments. Argh! So that's presumably the problem. http://lxr.mozilla.org/seamonkey/source/layout/html/forms/src/nsGfxTextControlFrame2.cpp#587 We need to implement all those methods.
Assignee: anthonyd → brade
Status: ASSIGNED → NEW
Component: Event Handling → Editor
It'd be nice if keyboard shortcuts that were not handled by the current widget were passed back up to a defeault handler.. like ctrl+r, if not otherwise handled, should be passed back up the the reload callback mechanism. It would certainly reduce my frustration as I have to click out of the location bar, current form widget, or anything else which is not the "background" of the web page. This includes other things, like view source, new window, back, forward, etc. It's very annoying to have them only partially work :p
I'm not sure I agree with Dylan here-handing shortcuts in two different ways can be confusing to the users-after all, they don't necessarily know which keystrokes are tied to the widgets and which are tied to the browser-and when. I, at least, prefer consistency...but maybe that's just me. Any thought on this?
I don't understand. Dylan's proposal would make things more consistent, not less. Under his proposal CTRL+R would do the same thing whether you're in a textarea or not.<< handing shortcuts in two different ways can be confusing to the users >>This has been going on for decades, and occurs throughout mozilla - and moreover has nothing to do with what Dylan was suggesting! Keystroke overrides like the up and down keys are there already, and would not be affected by Dylan's proposal.
Right. Most people understand context sensitivity. In the context of a browser, ctrl+N makes a new browser window. When it doesn't work in a widget, frustration rises. The people who use keyboard shortcuts also tend to be the more advanced users who understand that ctrl+u in a text entry is likely to clear it, but in the main window it will view source (although it might be nicer if we could hint the context better to the user). If you've used vi, you'll understand better what I mean by context-related controls in applications.
Well, 1) I'm not sure I get it, and 2) what I get I don't necessarily agree with. Granted, this is a losing battle, but I think that PgUp/PgDn should affect the onbect with focus if it can be used in suck context (i.e. pointless to make PgUp active on a radio button, for example). This is what the bug description at least is about-I can see that PgUp/PgDn should behave differently in a large text area (i.e. scroll that text area if necessary). What I'm not so sure about is something like CTRL-U. I'm using a mac here, so CTRL-U would only be a keystroke for an item on the page (i.e. it is not used for regular functions). I do not, however, know why CTRL-U would clear a text box, contrary to the suggestion above. I would consider myself an "advanced user" but havenot used vi in what seems like eons. Not all advanced users are unix/linuxheads or use vi before breakfast in the morning. Moving along on the topic though, I'd say that if, say CTRL-Z "undoes" I don't want a button to be able to take that functionality away from me. From what I understand, that's the proposal here. If I understand correctly then, and this is the case, the Summary of this bug should be changed to encompass this change of direction, or if that's not an option then a new bug should be opened. If I'm wrong, please let me know, and accept my apologies in advance. I guess this discussion (prompted by my ignorance perhaps) should be taken off bugzilla and to e-mail, so if you can enlighten me, I'd welcome the insight-and then I'll stop spamming your accounts:).
Right.. the behaviour is inherited. The global scope is the browser window frame. All the relevant hotkeys work in it (ctrl+n, ctrl+u, ctrl+<-, ctrl+->, etc). When you focus a part of it which is a widget, it would take control of some of those hot keys (for the local scope) -- but would leave others intact. IE: if I click into the text entry widget, ctrl+n still opens a new window (unlike now, where it just not one damned thing). This is more consistent and intuitive. FYI: ctrl+U is an emacsim which clears a line. ctrl+y should do the same thing in Windows (as it's a common convention from DOS and OS/2 days), but I don't think it works everywhere (like ctrl+u does in Gnome). When your clipboard is overwritten by selecting the text (for a line clearing delete), you begin to appreciate ctrl+u that much more! ;)
Please stop polluting this bug. There *is* a reason why pageup/down aren't scrolling in a textarea. I am working on a fix!
Status: NEW → ASSIGNED
I didn't apply the patch and run it, but it looks good r=rods
fix checked in note: pageup/pagedown don't move the caret but instead just scroll; this is a known bug (#4302).
Status: ASSIGNED → RESOLVED
Last Resolved: 18 years ago
Resolution: --- → FIXED
Whiteboard: fix in hand, getting sr
Another bug I've found is that, in 2001042708, ctrl+a in the location bar does NOT select all text. Looks like most of the shortcut stuff is broken :(
Dylan--are you using Linux? If so, Control-A won't select all. There is a bug floating around somewhere on that issue (it'll need to be a different keybinding on Linux unless you change your accelerator to Alt so it'd be "alt-a". Regardless, that is a completely different issue from page up/down scrolling.
Yeah, I use Linux. Are there any docs on the arch specific parts of Moz for UNIX? I'd really like to go over them with a fine-intruction debugger sometime, so I don't have to feel like the unloved redheaded stepchild when I compare Moz's performance to Win32 builds on slower machines (as well as silly bugs like ctrl+a).
Dylan--the select all discussion belongs in another bug (#81243)
works on that URL now....verified in 5/24 build.
Status: RESOLVED → VERIFIED
Could we update this to move the caret as well? There's nothing more frustrating than to page up a few times, then hit the arrew cursor and end up right back where I started!
Sorry, no, we can't update this bug. The issue you are talking about is covered in another bug. See bug #4302. A patch would be very welcome there ;-).
You need to log in before you can comment on or make changes to this bug.