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

Status: NEW

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

Description

[Akkana Peck]

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

[saari (gone)]

Depends on 24645

Comment 2

[Gwyn Judd]

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).

Comment 3

[Gwyn Judd]

> 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

[saari (gone)]

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

Comment 5

[Akkana Peck]

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.

Comment 6

[saari (gone)]

Is this a loss on unix? It isn't on Windows.

Comment 7

[Akkana Peck]

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

[saari (gone)]

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.

Comment 9

[saari (gone)]

setting priority

Comment 10

[Peter Trudelle]

Mass-moving most M15 bugs to M16

Comment 11

[Kathleen :Brade]

*** Bug 35325 has been marked as a duplicate of this bug. ***

Comment 12

[leger]

Putting on [nsbeta2-] radar.

Comment 13

[Peter Trudelle]

Mass-moving nsbeta2- bugs to M20

Comment 14

[Akkana Peck]

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

[ckritzer (gone)]

Mass update:  changing qacontact to [e-mail]

Comment 16

[Peter Trudelle]

no time for this, nsbeta3-/future/helpwanted

Comment 17

[Loco]

Updating QA Contact.

Comment 18

[Loco]

Anyone feel like this warrants an RTM honorable mention? -d

Comment 19

[saari (gone)]

Target Mozilla 1.0

Comment 20

[Jesse Ruderman]

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.

Comment 21

[saari (gone)]

mozilla 0.9

Comment 22

[Jesse Ruderman]

Any reason this bug is marked as linux-only?

Comment 23

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Perhaps because nobody has bothered to see if it exists on other platforms
(although I would assume it does)?  Have you?

Comment 24

[Randell Jesup [:jesup] (needinfo me)]

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.

Comment 25

[Akkana Peck]

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

[saari (gone)]

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?

Comment 27

[Akkana Peck]

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

[saari (gone)]

That just doesn't seem like good UI to me, but whatever. 

Comment 29

[Matthew T (active 1999-2002)]

This is 4xp on Mac, too. For scrolling back into view when you type, see bug 
64170.

Comment 30

[Matthew T (active 1999-2002)]

*** Bug 57961 has been marked as a duplicate of this bug. ***

Comment 31

[Jesse Ruderman]

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

[Lakespur Roca]

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.

Comment 33

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

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.

Comment 34

[Akkana Peck]

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

[timeless]

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

[Matthew T (active 1999-2002)]

> 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

[Loco]

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

[Randell Jesup [:jesup] (needinfo me)]

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.

Comment 39

[Akkana Peck]

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.

Comment 40

[Akkana Peck]

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

[Blake Ross]

Fix for 62431 didn't fix this; GetScrollableView() is never called on page 
up/down when in textfields.

Comment 42

[Hixie (not reading bugmail)]

Reassigning QA Contact for all open and unverified bugs previously under Lorca's
care to Gerardo as per phone conversation this morning.

Comment 43

[Madhur Bhatia]

QA contact updated

Comment 44

[sairuh (rarely reading bugmail)]

*** Bug 86765 has been marked as a duplicate of this bug. ***

Comment 45

[Andrew Doull]

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

[savardd]

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

Comment 47

[Kathleen :Brade]

*** Bug 170364 has been marked as a duplicate of this bug. ***

Comment 48

[Michael Lefevre]

*** Bug 171936 has been marked as a duplicate of this bug. ***

Comment 49

[Randell Jesup [:jesup] (needinfo me)]

Resetting target from 1.0.1

I'm willing to do this if someone would point me in the right direction.

Comment 50

[Randell Jesup [:jesup] (needinfo me)]

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

[Randell Jesup [:jesup] (needinfo me)]

Attachment: 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.

Comment 52

[Randell Jesup [:jesup] (needinfo me)]

Attachment: Updated patch

I originally did the patch against an older version.  Updated patch for current
trunk

Comment 53

[[e-mail]]

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

[[e-mail]]

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

[[e-mail]]

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

[Randell Jesup [:jesup] (needinfo me)]

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

[[e-mail]]

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

[Simon Fraser [no longer active]]

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.

Comment 59

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

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

[Simon Fraser [no longer active]]

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

[Kathleen :Brade]

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

[Paul Rogers]

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

[Peter Reynolds]

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.

Comment 65

[Vincent Lefevre]

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

[Nicolas Barbulesco]

(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

[Sylvestre Ledru [:Sylvestre]]

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.

Comment 71

[nvlquack]

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.

Comment 72

[gliu20]

(In reply to Randell Jesup [:jesup] (needinfo me) from comment #38)

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.

I think I'd prefer this version of the expected behaviour. However, maybe one clarification is to scroll the item with focus if it's "scrollable in the direction". That means if you are scrolling down in a textarea, and you are at the end of the textarea, we will pop out of the textarea to start scrolling the parent.

This closely follows the expected behaviour when using the mousewheel to scroll and the cursor is hovering over a textarea: When the textarea is scrollable in the desired direction, scroll the textarea. If not, scroll the parent.

This preserves the expected user behaviour of allowing scrolling inside the focused element while also allowing scrolling the parent as well.

Comment 73

[Hsin-Yi Tsai (she/her) | away [:hsinyi]]

Hi James,
It looks to me that this bug and bug 1239595 are duplicates. I am flagging you here because I am not quite sure if/how my action of setting duplication causes unexpected tracking consequences for the Web Compatibility:Knowledge Base bugs. These two platform bugs block different Knowledge Base bugs.

Comment 74

[James Graham [:jgraham]]

If they're dupes the right thing do do is to dupe the core bugs, dupe the knowledge base bugs, and ensure that the remaining kb bug is updated to block all the known site reports, and maybe add some text to the kb bug about the additional symptoms to look for. Unfortunately we don't yet have tooling to handle this automatically.

Comment 76

[Hsin-Yi Tsai (she/her) | away [:hsinyi]]

Hi Jamie and Masayuki,
We had discussions in bug 1806931 comment 14 which I believe is relevant to this issue. Apparently there are webcompat interests here, while there are also a11y concerns. Is there a compromised-but-acceptable solution to both webcompat and a11y? Bug 1806931 comment 14 seems to indicate no, but I wanted to ensure we're all aligned with the conclusion and the next steps. Thanks.

Comment 77

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

Well, we could redirect the commands to nsISelectionController for the page here. So, technically, it's fixable without big patches.

On the other hand, I'm still worry about new complaints about the new/Chrome behavior. I think that we need scenarios that when users feel inconvenient with current behavior to solve the a11y concerns.

Comment 78

[James Teh [:Jamie]]

I agree that the concerns are contradictory and I haven't come up with any compromise solution. That said, regarding web compat, as I understand it, Chromium have acknowledged that they consider the current Chromium behaviour to be a bug. If they were to fix this, that would partially resolve the web compat issue here in a way which is better for accessibility. Of course, it's difficult to know if/when this is likely to get attention from them.

Comment 79

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

It might be a solution to fix the Chromium behavior by us.

Comment 80

[Hsin-Yi Tsai (she/her) | away [:hsinyi]]

(In reply to James Teh [:Jamie] from comment #78)

I agree that the concerns are contradictory and I haven't come up with any compromise solution. That said, regarding web compat, as I understand it, Chromium have acknowledged that they consider the current Chromium behaviour to be a bug. If they were to fix this, that would partially resolve the web compat issue here in a way which is better for accessibility. Of course, it's difficult to know if/when this is likely to get attention from them.

Good reminder! We're going to take this to our contact on the Chromium team.

Comment 81

[Vincent Lefevre]

If I understand correctly, the Chromium bug is about a textarea (e.g. in the bug report: "Type some text on the textarea"), while the Mozilla bug is about single-line text fields (in the bug description: "Since text fields don't know how to scroll", which is not true for textareas).

Comment 82

[James Teh [:Jamie]]

(In reply to Vincent Lefevre from comment #81)

If I understand correctly, the Chromium bug is about a textarea (e.g. in the bug report: "Type some text on the textarea"), while the Mozilla bug is about single-line text fields (in the bug description: "Since text fields don't know how to scroll", which is not true for textareas).

That's true. However, as I noted in bug 1806931 comment 13:

[Not consuming page up /down is] perhaps reasonable for single line inputs, which is the case here. I'd argue it isn't reasonable for multi-line inputs, though, and contentEditables can't specify whether they're multi-line or not in a standard way as far as I know, so this also applies there.

Also, in bug 1806931 comment 14, :masayuki noted:

Even a single line input may have big height like a multi-line input. Therefore, I think it could make users confused too.

Comment 83

[Vincent Lefevre]

There are pages that put the focus in a text field by default. So the current behavior is rather bad. Or perhaps there should be an option to control the behavior.

Comment 84

[James Teh [:Jamie]]

I don't think it's constructive to argue about this at length :), but to provide an alternative perspective, it's debatable whether the browser's behaviour is bad or whether the site is behaving badly. Arguably, the browser is doing exactly what it's supposed to do: when focus is in a text field, cursor navigation and scrolling should be restricted to the text field. If the intention is that the page should be immediately scrollable by the user, the page shouldn't set focus to a text field in the first place.

An option is one possibility, but this is obscure enough that I suspect most users won't know what the option means or won't know to look for it.

Comment 85

[Vincent Lefevre]

(In reply to James Teh [:Jamie] from comment #84)

An option is one possibility, but this is obscure enough that I suspect most users won't know what the option means or won't know to look for it.

When affected by an issue or wanting a different behavior, users often search the web (now, there's also AI) and will find the answer if the option is present.

BTW, Firefox could also also detect that the [Page Up] / [Page Down] keys are used in a single-line text input while they have no effect and propose the option as a tip.

Comment 86

[Randell Jesup [:jesup] (needinfo me)]

So, as the patch author from 22 years ago... I don't think my patch will apply anymore. :-) I regret not pushing people to do something, however - we could have had a partial fix 22 years ago. However, what my patch tried to do could still be valid (fix this for the 1-line text input case). It really sounds like Chrome isn't likely to change their behavior anytime soon. I don't think our users will get that annoyed if we fix the one-line text case.

masayuki - you indicated it can be fixed for the simple case fairly easily, correct?

Comment 87

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

Yeah, I think so. sInputHandlers does not register the PageUp and PageDown as page scroll keys. So, it can have them, and SelectionMoveCommands can redirect the command to PresShell.

Comment 88

[Hsin-Yi Tsai (she/her) | away [:hsinyi]]

(In reply to Masayuki Nakano [:masayuki] (he/him)(JST, +0900) from comment #87)

Yeah, I think so. sInputHandlers does not register the PageUp and PageDown as page scroll keys. So, it can have them, and SelectionMoveCommands can redirect the command to PresShell.

Hey Masayuki and here,
Trying to push for a clear next step here. Am I right that we can go implement the 1-line text input case without waiting on the Chrome bug to be fixed? Or should I mark this bug as webcompat:blocked instead?

Comment 89

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

I meant that it's easy to change our behavior for aligning to Chrome, but Jamie and I (and also the Chrome's bug reporter) don't think that Chrome's behavior is reasonable. So, I think Chrome developers should change their behavior unless they believe their behavior is better.

Comment 90

[Daniel Holbert [:dholbert]]

Attachment: testcase 1

Here's a testcase, for convenience with testing this issue, and to help with reasoning about how our behavior currently differs from other browsers (and how this issue differs from e.g. bug 1239595 which was brought up as a possible-dupe but I think is in fact quite different).

STR for this testcase:

1. Scroll down a bit and click to focus the text input or the textarea.
2. Press your PageDown key repeatedly.

EXPECTED RESULTS:
After one or more PageDown keypresses (enough to reach the end of the text control), any subsequent PageDown keypresses should cause the top-level document to be scrolled. (In particular: when no more scrolling/caret-moving can be done inside the text control, then additional PageDown keypresses should be targeted at the nearest containing scrollport; along the lines of jesup's intuition in comment 38.) This is what happens for mousewheel scrolling, basically.

ACTUAL RESULTS:
PageDown just stops having any effect once the caret reaches the end of the text control.

Firefox gives ACTUAL RESULTS.
Chromium/WebKit give EXPECTED RESULTS.