Open Bug 27771 Opened 24 years ago Updated 7 days ago

page up/down when focus is in text field should scroll containing page

Categories

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

defect

Tracking

()

People

(Reporter: akkzilla, Unassigned)

References

Details

(Keywords: access, helpwanted, polish)

Attachments

(1 file, 1 obsolete file)

Click in a text field, then hit page up/down. Since text fields don't know how
to scroll, the event should bubble up to the page and be handled there, but
instead, nothing happens. (4.x scrolls in this case.)

I notice that htmlBindings.xml has page up/down bindings for text fields. It
shouldn't, and they should be removed, but removing them doesn't fix this bug.
Depends on 24645
Status: NEW → ASSIGNED
Depends on: 24645
Target Milestone: M15
As a note to this. If the text box contains more text than can be contained,
page up/down seems to "attempt" to scroll but actually doesn't. (It flickers up
but then jumps down again).
> As a note to this. If the text box contains more text than can be contained,

arrgh

for that second "contained" read that as "shown". sorry
Single line text fields do not respond to page up/down on 4.x for Win or IE.
Multiline text fields have another bug describing the flickering attempt to scroll.

Moving to M20
Target Milestone: M15 → M20
This is a major usability loss compared to 4.x, since I have to use twice as
many mouse clicks to navigate around in a bugzilla page, and twice as many
transitions from keyboard to mouse.  Nominating for beta2 consideration since if
I didn't work here, this would stop me from switching to mozilla.
Keywords: beta2
Is this a loss on unix? It isn't on Windows.
Yes, in 4.x on Unix, when focus is in a text field, page up/down will still
scroll the containing page.  I didn't know until just now that Windows didn't
behave that way (wow, Windows users put up with a lot! :-)

Shouldn't our event model just handle this magically if it were working right?
Yeah it should... I think... Well, I know for sure that the XBL bindings for 
page-up and page-down are getting called (change their commands to be arrow left 
or right and you can remap page up/down). The question then becomes why the 
command dispatcher doesn't seem to be executing those. 

Ok, I'll pull this back to M15 then and figure out what dimesion those commands 
get lost in.
Target Milestone: M20 → M15
setting priority
Priority: P3 → P1
Mass-moving most M15 bugs to M16
Target Milestone: M15 → M16
*** Bug 35325 has been marked as a duplicate of this bug. ***
Keywords: nsbeta2
Putting on [nsbeta2-] radar.
Keywords: beta2
Whiteboard: [nsbeta2-]
Mass-moving nsbeta2- bugs to M20
Target Milestone: M16 → M20
Target Milestone: M20 → Future
This is still a big functionality loss compared to 4.x (have to do a lot more
clicking to navigate pages like bugzilla).  Adding 4xp keyword and nominating
for nsbeta3.
Keywords: 4xp, nsbeta3
Keywords: polish
Mass update:  changing qacontact to ckritzer@netscape.com
QA Contact: janc → ckritzer
no time for this, nsbeta3-/future/helpwanted
Keywords: helpwanted
Whiteboard: [nsbeta2-] → [nsbeta2-][nsbeta3-]
Updating QA Contact.
QA Contact: ckritzer → lorca
Anyone feel like this warrants an RTM honorable mention? -d
Target Mozilla 1.0
Target Milestone: Future → mozilla1.0
Blocks: 27661
pgup/pgdn in a textbox probably needs to unfocus the textbox as well as 
scrolling the page down, so that if the user presses an arrow key later, the 
page doesn't scroll back to the textbox.
Target Milestone: mozilla1.0 → mozilla0.9
mozilla 0.9
Any reason this bug is marked as linux-only?
Perhaps because nobody has bothered to see if it exists on other platforms
(although I would assume it does)?  Have you?
I don't know about others, but when I report a bug, unless I have proof it
affects other OS's I set OS to what I tested it on.  I suspect others do the
same.  There's no "unknown" in OS, nor is it a multiselect.

In this case, I suspect that, plus the fact that this feature was in 4.x NS for
Unix but not in 4.x NS for win32 caused it to be listed as Linux.  It affects
all OS's, though, so OS -> ALL.
OS: Linux → All
Saari's first comment asserted that mac and windows apps don't normally scroll
the containing page like Unix apps do if the focus is in a text field.  I don't
know if any other windows/mac people have looked at the bug, nobody else seems
to have expressed an opinion.  Seems like it would be useful functionality for
everybody, but that's a Unix person speaking. :-)
Well, I just checked IE5 on mac, and it does in fact scroll the page. So I dunno
what the *right* thing is, but I'm marking it as all platforms for now.

Once the text field is scrolled off the page I can type in it and it doesn't
scroll back into view. So much for usable UI. Is it supposed to scroll back into
view on unix?
Hardware: PC → All
Just checked Linux 4.7: it doesn't scroll back into view, and typed text does
continue to go into the off-screen text field.
That just doesn't seem like good UI to me, but whatever. 
This is 4xp on Mac, too. For scrolling back into view when you type, see bug 
64170.
*** Bug 57961 has been marked as a duplicate of this bug. ***
Bug 64170 is for scrolling within the textbox, not for scrolling the page to 
make the textbox visible.  (If you file a new bug for that, please cross-
reference it with 64170.)  I still think pgup/pgdn in a single-line textbox 
should blur the textbox in addition to scrolling the page, though.
It looks like there are differing opinions on what the Page up and Page down
buttons should do.

Behavior 1,  when the Focus is any where but a multiline or scrolling text box
the keys move the view of the page up or down one view full. When it is in a
multiline or scrolling text box the PageUp or PageDown keys move view of the
text in the box up or down one view full.

Behavior 2, The Page Up and Pge Down always move the web page view up or down
one view full.

The question now is which one is right So we can fix this bug properly.
Regardeless I think agree that it shouldn't do nothing and it shouldn't flicker
the text.

My two cents are that page up and down be used for moving the web page view for
two reasons, there are many instances of this being usefull and there are
relatively few large test fields that would require scrolling that could not be
easily handled by the up and down arrows.
There could be some other complicating issues, like IFRAMEs (which is the page?).

Even with those complications, I think it could be boiled down to 2
possibilities (plus some ugly ones in the middle):

 2) outermost scrollbar -- in other words, scroll the containing page rather
    than the IFRAME, and the page rather than the TEXTAREA

 1) innermost scrollbar -- the reverse

Then there's the somewhat ugly issue of what to do if a scrollbar is not
present -- do we do nothing, or do we skip to the next one in/out?  In
other words, if we choose (2) and the user is doing message composition in
a webmail program where there is a large scrolling textarea occuping most
of a non-scrolling page, should PgDn scroll the textarea?  Moving to the
next scrollbar in/out would be inconsistent, but sometimes useful.  I'm
not sure which should win.

But that's a digression, since I think the real point of this bug is that we
ought to do something like (1) or (2) or something in between, rather than
doing nothing.
I guess I'd expect the text area, rather than the containing page, to scroll if
the focus was there, but could live with either solution.

The important thing is that the containing page should scroll when focus is in a
text field (single line, non scrollable).

Personally, I'd prefer that it didn't blur the text field -- I do sometimes
scroll down to check background of the bug then go back to typing -- but that's
a minor issue.  If you don't like being able to type when the widget is off the
screen, maintaining focus and auto-scrolling on typing would be a better solution.
ms intellimouse scrolling does innermost scrollable object.
ie style 1
do we skip to the next one in/out? it does

do i like their approach? yes.
> My two cents are that page up and down be used for moving the web page view for
> two reasons, there are many instances of this being usefull and there are
> relatively few large test fields that would require scrolling that could not be
> easily handled by the up and down arrows.

An obvious counterexample is message composition fields in Webmail accounts -- 
such messages may be very long, so Page Up and Page Down would be quite useful 
for scrolling through them. For that reason I vote for Behavior 1. This would 
also provide consistent behavior between IFRAMEs and TEXTAREAs.
A pref panel would solve this problem-but then we'd have to do it both ways.  The 
thing is that there are two types of users: those who would use this, and those 
who won't:).  

If we have to choose one, I'd say that maybe 20% of users use their browsers 
primarily for e-mail.  The rest don't.  While I see the merit of using focusable 
iframes as far as PgUp/PgDn are concerned, they are not the majority of users by 
a long shot (I think, since I have no hard evidence to back this statement).
My 2 cents: page up/down should scroll the item with focus if it's scrollable.
If it's not scrollable, pop out one level, wash, rinse, and repeat.  Simple,
makes sense to people, doesn't surprise people.

So, if it's in a scrolling text field, it will scroll it.  If the text field
isn't scrollable, it will scroll the window (or frame/whatever) the text field
is in.

As for how to deal with a multiline text field that doesn't have a scrollbar -
it's not scrollable.  So page up/down would scroll the window.  (this is more
arguable).

This is the behavior of most wheel-mouse implementations I think.
Keywords: nsbeta2, nsbeta3
Whiteboard: [nsbeta2-][nsbeta3-]
Speaking of the mousewheel, mousewheel should also scroll the page when focus is
in a text field (or also, if possible,  in a textarea that doesn't have a
scrollbar).  Should that be a separate bug (or is it already?)  I long for this
several times a day.
Bug 62431 covers mousewheel scrolling needing to get the parent.  The fix may be
the same for both, though -- bryner suggests that
nsGfxTextControlFrame2::GetScrollableView should return the parent if the text
conrol is not scrollable, which sounds very sensible, and I'm going to play with
that and see if it fixes the problem.
Fix for 62431 didn't fix this; GetScrollableView() is never called on page 
up/down when in textfields.
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
Target Milestone: mozilla0.9 → mozilla1.0
QA contact updated
QA Contact: gerardok → madhur
*** Bug 86765 has been marked as a duplicate of this bug. ***
Target Milestone: mozilla1.0 → mozilla0.9.8
I have made a suggestion in bug 29086 that implies that Mozilla should use the 
first version of the semantics suggested by David Baron (Scroll the outermost 
iframe eg containing page), but use the scroll lock key to change to the second 
semantic (Scroll the innermost frame capable of responding to the page up/page 
down request).

Just thought I'd direct interested people to that bug for my full suggestion.
Hello,

  My 2 cents, I think that anything that don't have scroll bar shouldn't keep
the scroll events for themselves.  
  
  Radio Buttons, Text Field, CheckBox, Image, etc shouldn't keep the scroll
events but bubble them to their container.  So, focus on a text field shouldn't
prevent scrolling the whole page.

Thanks
Target Milestone: mozilla0.9.8 → mozilla1.0.1
QA Contact: madhur → rakeshmishra
*** Bug 170364 has been marked as a duplicate of this bug. ***
QA Contact: rakeshmishra → trix
*** Bug 171936 has been marked as a duplicate of this bug. ***
Resetting target from 1.0.1

I'm willing to do this if someone would point me in the right direction.
Target Milestone: mozilla1.0.1 → ---
Note: this is (already) an accessibility bug; people who don't have or can't
easily use mice would find usage easier if page up/down bubbled.
Attached patch Patch for 1-line input widgets (obsolete) — Splinter Review
This is a patch that solves the problem for 1-line text input widgets.	It's a
bit kludgy (though nsFocusController already is incestuous with the different
text input elements), and doesn't handle multi-lines (which is more fun).

The "right" solution is to change the interfaces so that a command can return
that it didn't really want to be run after all, and let the search continue. 
This would require significant changes to GetControllerForCommand() and the
callers of the commands.
Attached patch Updated patchSplinter Review
I originally did the patch against an older version.  Updated patch for current
trunk
Attachment #113617 - Attachment is obsolete: true
This to the best of my knowledge so far is how this bug should be fixed:

1. In nsEditorController.cpp create a new method that only registers those
commands needed for <input>.

2. In nsEditorRegistration.cpp register a new component that calls that method
instead of the existing method.

3. In nsHTMLInputElement.cpp create an instance of the new component instead of
the existing component.
So, armed with additional knowledge (thanks brade!) the problem is this:
platformHTMLBindings translates PageDown for browser and textarea, not input
however the browser translation is intercepted by input anyway...
So, the fix now appears to be to search for the controller starting with the
element on which the key was mapped to a command.
The code for that belongs in nsXBLPrototypeHandler.cpp;
delete lines 263-294 (and the else on line 295),
and fix the method currently at line 547
(and rename it to GetControllerForCommand for consistency).
It should work like the same method in nsFocusController.cpp,
but starting at the event receiver, not the focused element.
How do we deal with the more general case here?  Pagedown in a multi-line
textarea?  That requires the command handler to be able to say "sorry, no
thanks, give someone else this command".

You could have page up/down bubble out if there are no scrollbars, or you could
follow CUA, and have them do beginning/end, and only bubble out if you're
already on the first or last line.

Note: I don't want to discourage anyone from solving this for the "simple" case
of single-line widgets first.
Be very careful. When the focus is in the mailnews quick search field, you don't
want the delete key to say "nothing to delete here, try bubbling up".
I think we need 2 things here:
1. Commands on the editor controller to handle page up/page down, that do the
   right thing for single-line inputs, and scrollable ones.
2. Some way that a command can return NS_ERROR_COMMAND_NOT_HANDLED, and have
   the command dispatch system look for another controller that will handle it,
   or have the controller call IsCommandEnabled() (which I think it does already),
   but be willing to look up the controller chain if necessary.
Having keys start applying to a different widget without a change in focus seems
like bad UI in general.  Do we really need a mechanism to implement that
behavior?  I expect that if PgDn does something, I can hold it down for a bit,
and when it stops doing what it's doing it won't start doing something else
(like scrolling the page instead of the textarea).

Or am I misunderstanding what you're trying to do?
dbaron: that would be affected by the implmentation of the commmand.
NS_ERROR_COMMAND_NOT_HANDLED should only be returned when it's OK to dispatch
the command to another controller (i.e. only for non-scrollable things). If a
scrollable thing is scrolled to the end, the command should just return NS_OK.

This does highlight a difference between using a NS_ERROR_COMMAND_NOT_HANDLED
return value, and using IsCommandEnabled to implement command "bubbling". The
latter would cause the kind of behaviour that dbaron describes, so is probably
the wrong thing to do.
For the record, I still dispute the proposed fix by Simon (comment 58 and
comment 60).  While it might be a nice thing to have in the long run, I don't
think it solves the root of this bug.  In my opinion, the problem in this bug is
that the keybinding found a controller to handle the command but then didn't
dispatch it to the controller that wanted to handle it (it sent it based on focus).

An alternative, hacky solution to this issue would be to rename the commands so
that no controllers use the same command strings (kind of ugly and undesirable
but it would fix this issue).
I'm just a new Firebird user.  I'm seeing something I think is like this in
Firebird 0.7.  Sometimes when I go to a text page the keyboard page up/down keys
don't seem to do anything.  If I try the cursor arrow keys somewhen along the
various key presses trying to move things, then the page up/down seems to work
(focus shifted?).  But they don't always work.  Sometimes pressing once gives me
a page down, but pressing again produces no movement.  I noticed this especially
trying to read a news story from a "My Yahoo" page.
Is my problem related to this?

I'm using Thunderbird Trunk nightly.  Every day I paste a piece of text/HTML into an email.  The cursor is there at the end of what I have pasted, and I can type or backspace just fine.  But when I press CTRL-Home to go up to the top, it doesn't work until I use the mouse to click somewhere in the window.  I'm pretty sure this
is a new problem in the last month or two.
Assignee: saari → nobody
Status: ASSIGNED → NEW
QA Contact: trix → events
The behavior should be the one expected by the user, not the one imposed by the browser. So, it should probably be configurable.

This also concerns the arrow keys and the Home and End keys (not only page up/down), and even when a multi-line text field has the focus, it may be a good idea to scroll the page on up/down arrow keys (see example below).

I don't think that single-line fields and multi-line fields should behave differently (though this could be configurable), because these cursor keys are also used for the history in single-line fields.

Now, to give an exemple, some web sites automatically gives the focus to a text field on load, e.g. allocine.fr (single-line field, used for searching) and identi.ca (multi-line field, used to compose a message). In these two cases, the text field is initially empty (so that moving the caret up or down doesn't make sense ­— for single-line fields, browsing the history can make sense but not necessarily useful in this context). Moreover it is not immediately clear for the user that the text field has the focus, in particular because:
  * the focus hasn't been set explicitly by the user, but automatically by the web site;
  * Firefox doesn't show when the page has the focus and when it doesn't;
  * the text field with the focus may not be visible, even on load.
So, the user wonders why scrolling with the keyboard doesn't work, and even when one knows the web site, this behavior is quite annoying.

I think the behavior could be the following: By default, the cursor keys would have their normal effect for a text field that has the focus. Then there would be (configurable) exceptions (I don't like exceptions, but I think that here this is unavoidable for usability reasons). For instance, when a field is empty and/or when the focus has not been explicitly given by the user. Another one could be whether the cursor is at the end for the corresponding movement.
(In reply to Jesse Ruderman from comment #20)

> pgup/pgdn in a textbox probably needs to unfocus the textbox as well as 
> scrolling the page down

No. Not on Mac, anyway. On Mac, Page Up and Page Down just move the view. :-) (Window$ does horrible things.)
Decreasing the priority as no update for the last 2 years on this bug.
See https://github.com/mozilla/bug-handling/blob/master/policy/triage-bugzilla.md#how-do-you-triage 
about the priority meaning.
Priority: P1 → P5
Component: Event Handling → User events and focus handling

Hello 21-yo thread! Please fix this problem. It is crucial to my comfort to have this function on websites. I need the "Page Down" button to actually scroll the page when text field is focused. Please, I don't want to go back to Chrome for this function.

Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.