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)
Core
DOM: UI Events & Focus Handling
Tracking
()
NEW
People
(Reporter: akkzilla, Unassigned)
References
Details
(Keywords: access, helpwanted, polish)
Attachments
(1 file, 1 obsolete file)
1.47 KB,
patch
|
Details | Diff | Splinter Review |
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.
Comment 1•24 years ago
|
||
Depends on 24645
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
Comment 4•24 years ago
|
||
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
Reporter | ||
Comment 5•24 years ago
|
||
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
Comment 6•24 years ago
|
||
Is this a loss on unix? It isn't on Windows.
Reporter | ||
Comment 7•24 years ago
|
||
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?
Comment 8•24 years ago
|
||
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
Comment 11•24 years ago
|
||
*** Bug 35325 has been marked as a duplicate of this bug. ***
Updated•24 years ago
|
Target Milestone: M20 → Future
Reporter | ||
Comment 14•24 years ago
|
||
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.
Comment 15•24 years ago
|
||
Mass update: changing qacontact to ckritzer@netscape.com
QA Contact: janc → ckritzer
Comment 16•24 years ago
|
||
no time for this, nsbeta3-/future/helpwanted
Keywords: helpwanted
Whiteboard: [nsbeta2-] → [nsbeta2-][nsbeta3-]
Comment 18•24 years ago
|
||
Anyone feel like this warrants an RTM honorable mention? -d
Comment 20•24 years ago
|
||
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.
Updated•24 years ago
|
Target Milestone: mozilla1.0 → mozilla0.9
Comment 21•24 years ago
|
||
mozilla 0.9
Comment 22•24 years ago
|
||
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?
Comment 24•24 years ago
|
||
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
Reporter | ||
Comment 25•24 years ago
|
||
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. :-)
Comment 26•24 years ago
|
||
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
Reporter | ||
Comment 27•24 years ago
|
||
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.
Comment 28•24 years ago
|
||
That just doesn't seem like good UI to me, but whatever.
Comment 29•24 years ago
|
||
This is 4xp on Mac, too. For scrolling back into view when you type, see bug 64170.
Comment 30•24 years ago
|
||
*** Bug 57961 has been marked as a duplicate of this bug. ***
Comment 31•24 years ago
|
||
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.
Comment 32•24 years ago
|
||
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.
Reporter | ||
Comment 34•24 years ago
|
||
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.
Comment 35•24 years ago
|
||
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.
Comment 36•24 years ago
|
||
> 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.
Comment 37•24 years ago
|
||
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).
Comment 38•24 years ago
|
||
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.
Updated•24 years ago
|
Reporter | ||
Comment 39•24 years ago
|
||
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.
Reporter | ||
Comment 40•24 years ago
|
||
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.
Comment 41•24 years ago
|
||
Fix for 62431 didn't fix this; GetScrollableView() is never called on page up/down when in textfields.
Comment 42•24 years ago
|
||
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
Updated•23 years ago
|
Target Milestone: mozilla0.9 → mozilla1.0
Comment 44•23 years ago
|
||
*** Bug 86765 has been marked as a duplicate of this bug. ***
Updated•23 years ago
|
Target Milestone: mozilla1.0 → mozilla0.9.8
Comment 45•23 years ago
|
||
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.
Comment 46•23 years ago
|
||
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
Updated•22 years ago
|
Target Milestone: mozilla0.9.8 → mozilla1.0.1
Updated•22 years ago
|
QA Contact: madhur → rakeshmishra
Comment 47•22 years ago
|
||
*** Bug 170364 has been marked as a duplicate of this bug. ***
Updated•22 years ago
|
QA Contact: rakeshmishra → trix
Comment 48•22 years ago
|
||
*** Bug 171936 has been marked as a duplicate of this bug. ***
Comment 49•21 years ago
|
||
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 → ---
Comment 50•21 years ago
|
||
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.
Comment 51•21 years ago
|
||
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.
Comment 52•21 years ago
|
||
I originally did the patch against an older version. Updated patch for current trunk
Attachment #113617 -
Attachment is obsolete: true
Comment 53•21 years ago
|
||
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.
Comment 54•21 years ago
|
||
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.
Comment 55•21 years ago
|
||
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.
Comment 56•21 years ago
|
||
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.
Comment 57•21 years ago
|
||
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".
Comment 58•21 years ago
|
||
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?
Comment 60•21 years ago
|
||
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.
Comment 61•21 years ago
|
||
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).
Comment 62•21 years ago
|
||
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.
Comment 63•17 years ago
|
||
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.
Updated•15 years ago
|
Assignee: saari → nobody
Status: ASSIGNED → NEW
QA Contact: trix → events
Comment 65•13 years ago
|
||
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.
Comment 69•9 years ago
|
||
(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.)
Comment 70•6 years ago
|
||
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
Assignee | ||
Updated•5 years ago
|
Component: Event Handling → User events and focus handling
Comment 71•4 years ago
|
||
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.
Updated•2 years ago
|
Severity: normal → S3
You need to log in
before you can comment on or make changes to this bug.
Description
•