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
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
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.
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.
Mass-moving most M15 bugs to M16
*** Bug 35325 has been marked as a duplicate of this bug. ***
Putting on [nsbeta2-] radar.
Mass-moving nsbeta2- bugs to M20
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.
Mass update: changing qacontact to firstname.lastname@example.org
no time for this, nsbeta3-/future/helpwanted
Updating QA Contact.
Anyone feel like this warrants an RTM honorable mention? -d
Target Mozilla 1.0
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.
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.
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?
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.
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 updated
*** Bug 86765 has been marked as a duplicate of this bug. ***
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
*** Bug 170364 has been marked as a duplicate of this bug. ***
*** 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.
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.
Created attachment 113617 [details] [diff] [review] Patch for 1-line input widgets 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.
Created attachment 113629 [details] [diff] [review] Updated patch I originally did the patch against an older version. Updated patch for current trunk
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.
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.)