Closed Bug 65124 Opened 24 years ago Closed 23 years ago

Page up/Page down should scroll textarea

Categories

(Core :: DOM: Editor, defect, P3)

defect

Tracking

()

VERIFIED FIXED
mozilla0.9.1

People

(Reporter: tpowellmoz, Assigned: Brade)

References

()

Details

(Keywords: access)

Attachments

(1 file)

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
Based on bug 29082, it looks like the proper placement of the cursor after PgUp
and PgDn is bug 4302! bug 29082 also makes it sound like this was working at one
point, so this may be a regression.
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
Hopefully easy?
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.
-->brade
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.
QA Contact: gerardok → sujay
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
Blocks: 75348
r=cmanske
I didn't apply the patch and run it, but it looks good  r=rods
Whiteboard: fix in hand, getting sr
fix checked in

note: pageup/pagedown don't move the caret but instead just scroll; this is a 
known bug (#4302).
Status: ASSIGNED → RESOLVED
Closed: 23 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.