The ScrollPane acts on navigational keys by scrolling its content pane left/right/up/down. It installs event listeners to do so. However, it does not check if it is the current focus owner before acting on these events. This causes several problems:

- A Custom control which relies on the standard navigation provided by Scene will work perfectly out of the box, but breaks when it is put in a ScrollPane as the necessary KeyEvents are intercepted and don't bubble back up to Scene

- A Control that decides against consuming a KeyEvent (because it is for example at the end of its list) and leaves the event to bubble up to its Parent, but a ScrollPane is somewhere in between, will see that event swallowed

- All FX controls, even ones that just want default navigation, have to explicitly implement navigation keys in their input map (that's about 10 keys), or risk breaking when put in a ScrollPane. This wastes memory as these InputMaps are not shareable.

Furthermore, the ScrollPane is consuming these while not having explicit focus (ie. the user does not see the ScrollPane as being focused, but only a child inside it). In all other UI's I've tested (Mac/Windows/Various browsers), a scroll pane only consumes keys when it is the direct focus target.

The implementation seems like an oversight due to how events bubble up; KeyEvents are targetted at a Control, and within the substructure of such a control, a Control can decide how to handle these. However, when a KeyEvent bubbles up to containers (like ScrollPane, even though this is a Control), it should not act on these events unless it has the direct focus.

# Proposed Solution

Have ScrollPane do a check with isFocusedNode before deciding to consume these keys.

Controls that need standard navigation can be modified as part of this fix to rely on Scene navigation, saving the allocation of 10 input map slots per active control.