RFR: 8340852: ScrollPane should not consume navigation keys when it doesn't have direct focus [v2]

Martin Fox mfox at openjdk.org
Sat Oct 5 18:21:40 UTC 2024


On Sat, 5 Oct 2024 10:22:44 GMT, John Hendrikx <jhendrikx at openjdk.org> wrote:

> > Two rationales have been presented for removing PgUp, PgDn, Home, and End. One is that it’s inappropriate for a node to process a key event when it doesn’t have direct focus. This is not a generally accepted rule in any UI toolkit I’ve ever worked with (just think of how Shift+Right to extend the selection is implemented in most table views).
> 
> That will not change, those keys are processed by the focused control. Using Shift + Navigation key to extend selection will keep working as normal and the pane will scroll if necessary, but not because the scroll pane is handling that key (it would have no clue what to do on shift + right) but because the control involved will try to keep the cursor visible.

I said "think of how Shift+Right to extend the selection is implemented in most table views". I never claimed it was handled by the scroll pane or even that it should be. It is typically implemented by allowing an event/action/selector/whatever to bubble up to the enclosing table view to be acted on even if the focus lies on one of its descendants. I was just countering this (new) concept that a control shouldn't act on a keystroke unless it has direct focus. That's just not a generally accepted rule.

> Now, **custom** controls are a different matter. These may have relied on this behavior, and I think that's why this change should be mentioned explicitly in the release notes. They no longer get "scrolling" for free. However, I think even for these controls the default behavior is undesirable. We're again talking about focusable controls, and letting scroll pane have its way will mean those controls can scroll out of view. If it is a single view filling control (like a `*View`) it is likely these keys have been overridden by the custom control to provide better than default behavior.

If I understand you correctly you're once again citing a new rule, namely that PgUp and PgDn shouldn't allow the focused node to scroll out of view.

It is also not a generally accepted rule that if the default behavior isn't correct in all cases it should be removed.

I'm going to tap out of this conversation. I don't agree with these changes but don't think they will inflict much harm. I believe that if there's pushback from the developer community you will not get far using the novel principles you're citing (like the one outlined in the bug title). But perhaps I'm out of step on this and it's time for others to chime in.

-------------

PR Comment: https://git.openjdk.org/jfx/pull/1582#issuecomment-2395139975


More information about the openjfx-dev mailing list