Open Bug 27771 Opened 26 years ago Updated 20 days ago

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

Categories

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

Product:
Core
Component:
DOM: UI Events & Focus Handling
Type:
enhancement

Tracking

()

People

(Reporter: akkzilla, Unassigned)

References

(Blocks 1 open bug)

Details

(5 keywords)

User Story

user-impact-score:450

Attachments

(2 files, 1 obsolete file)

Updated patch
1.47 KB, patch
Details | Diff | Splinter Review
testcase 1
768 bytes, text/html
Details
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 patch — — Splinter 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
See Also: → 1806931
Blocks: 1886126
Severity: S3 → --
Type: defect → enhancement

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

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.

Flags: needinfo?(james)

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.

Flags: needinfo?(james)
Duplicate of this bug: 1239595
No longer duplicate of this bug: 1239595

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.

Flags: needinfo?(masayuki)
Flags: needinfo?(jteh)

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.

Flags: needinfo?(masayuki)

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.

Flags: needinfo?(jteh)

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

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

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

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

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.

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.

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

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?

Flags: needinfo?(masayuki)

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.

Flags: needinfo?(masayuki)

(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?

Flags: needinfo?(masayuki)

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.

Flags: needinfo?(masayuki)
Attached file 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.

Duplicate of this bug: 1886126
No longer blocks: 1886126
Flags: needinfo?(rjesup)

Jamie - It seems like Chrome/chromium isn't likely to address this soon (or perhaps ever); 6 years with no action beyond an occasional comment from a user.

Given that and that we get repeated webcompat issues that link back to this, what's our best path forward? We certainly know how we would fix this; what would be the downside impact of doing so?

Flags: needinfo?(rjesup)
Flags: needinfo?(masayuki)
Flags: needinfo?(jteh)
User Story: (updated)

I described the downside impact in bug 1806931 comment 11:

The key point here is that the focus is within an editable element. When focus is within an editable element, I would expect cursor keys (including page down) to move the caret within the bounds of the editable element, not to scroll the page. Even with caret navigation enabled, cursor keys don't walk outside the bounds of an editable element. It seems surprising to me that page down would suddenly start scrolling the document once the caret hits the bottom of the editable element, potentially scrolling the editable element off the screen while it still has the focus.

The proposed solution violates keyboard expectations in an editable element, wherein cursor keys are normally confined. As I noted in comment 78, I don't know of a compromise here. Essentially, as I see it, we're confronted with a situation where we need to implement buggy behaviour (potentially making things worse for keyboard accessibility in editable content) in order to be more web compatible with buggy behaviour in other browsers.

Flags: needinfo?(jteh)

I'm less concerned with mirroring other browsers (though it comes up repeatedly as a WebCompat issue). The reason I wanted to fix this originally was that I was working on a browser which ran as a thin client in cable settop boxes, and they had either IR remotes with 4 directionals and page up/down buttons, or IR keyboards with arrows and page up/down keys. It was very annoying that focusing a text element broke the ability to page up/down, since page up/down in a 1-line text element has no purpose. So from that point it made sense (and bubbling page up/down up if it's a multiline text element with no scrollbars, and perhaps bubbling if it's multiline at already fully scrolled in that direction). It was annoying to have to 'escape' a text element in order to view more of the screen (and they were displaying on pre-HD TVs, so you did LOTS of scrolling/pageup/down)

However, as you indicate, this will have issues for predictability for keyboard accessibility.

So the question is if there's a way to solve both of these. There might not be.

Thanks for the use case explanation. That's helpful.

I've tried to come up with a way to solve both, but have come up blank. Eventually, we'll have an Accessibility section in Settings, so a pref could work here. Normally, I don't think a pref is the right solution in cases like these; that effectively means we're sitting on the fence and we should ideally try to come up with the best compromise for everyone by default. However, there are solid arguments on both sides here. Even for accessibility, some argue that not being able to scroll with the keyboard (if they don't realise they can scroll by tabbing out of the editable area) is a keyboard accessibility issue.

Thanks, jesup. That's an interesting case for me. Indeed, with a remote control (meaning working with smaller viewport), PageDown and PageUp may have different expectations from the keyboard for PC. In the case, like Jamie said, adding a pref for the embedder may be a good solution. On the other hand, if it's the only scenario, I don't think we get same web-compat reports repeatedly.

On possible solution is, although it's not smart, repeatedly pressing PageDown/PageUp with NOOP result allows to "unlock" the scroll target. However, currently, we cannot check the source event in the command handler directly. So, we need some tricky idea to do this (maybe the focused editor can have the state?). However, even with doing this, users must expect that from the first key press. So, anyway this issue will repeatedly be reported.

Flags: needinfo?(masayuki)

The original usecase isn't relevant; just history. We do get webcompat reports against this on a regular basis, however, like in bug 1806931

Pressing multiple times would work, but not be obvious. Users usually will try several times if it doesn't work at first, which is the appeal. However, it's not a great solution since users will hit this again and again.

And see Jamie comment in https://bugzilla.mozilla.org/show_bug.cgi?id=1806931#c11 as well.

What does chrome do in a textfield? Looks like the (mostly) solved their textarea bug: https://issues.chromium.org/issues/41417806#comment33

Note also that when a textfield has the focus and is not visible, Firefox has an erratic behavior when one does PageDown or PageUp. Sometimes it does nothing, sometimes it scrolls the page to an unrelated position.

You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: