Sliders should receive keyboard focus on mouse click

[irwir]

Issue type

UX/Interaction bug (incorrect behaviour)

Description with steps to reproduce

When you click on a slider (or any UI object that accepts input from the arrow keys) it should receive keyboard focus.

1. Click on a note or rest in the score.
2. Open the Mixer and click on a volume slider.
3. Try to move the volume slider with the Left and Right arrow keys.
   • Not the Up and Down arrow keys because these are used for navigation in the Mixer, not to change values.

Expected result: The volume slider should move up and down.

Actual result: Navigation occurs in the score.

• Though changed pitches or shifted texts (tempo) are score-damaging and not mere navigation

What is the latest version of MuseScore Studio where this issue is present?

4.4.2 and latest nightly

Regression

Yes, this used to work in MuseScore 3.

Operating system

Windows 11

Additional context

Objects that do not accept input from the arrow keys (e.g. buttons, checkboxes) should NOT receive focus on click. For example, if you click the 'mute' button in the Mixer, or a duration button in the toolbar, focus should remain in the score.

For objects that DO receive focus on click, when it receives focus this way, the dark focus rectangle should NOT be displayed. This rectangle should ONLY be displayed if the object received focus by pressing a keyboard shortcut such as arrow keys or tab.

For example, consider the input field next to the pan control in the Mixer. The correct states are:

Not focussed	Focussed via mouse	Focussed via keyboard

In the middle image, it still has keyboard focus, but the dark focus rectangle is not displayed. This is the correct behaviour.

Note: When focussed via keyboard the text in the field is selected. This is correct behaviour. When focussed via mouse the text is not selected. This is also correct behaviour. The user can double-click to select the text or press an arrow key to deselect it.

[bkunda]

@shoogle can you please investigate this one for us? The issue needs more information for us to determine what's actually being requested (I.e. change from current behaviour, or a report of an actual bug).

[MarcSabatella]

I wouldn't be in a hurry to change this. It is worth noting this has gone back and forth a bit over the years. There were times (MU3) when clicking a mixer button would take focus, and this was not popular - we got lots of complaints. Especially because people would want to move a mixer control and then hit Space to start / stop playback and they were annoyed it would always take an extra click to put focus back in the score - which came with its own price if you were in note input mode at the time. So I wouldn't be in a hurry to reinstate that behavior. See for instance https://musescore.org/en/node/315192 and the various threads that link to it.

On the other hand, it would be great to have an easily-discover way to explicitly transfer keyboard focus to the mixer. I have enabled the text boxes for the volume, and after clicking in there, I can arrow or tab around, and use Left/Right to move the slider. But that's far from ideal.

An alternative would be to special-case by key - after clicking a slider, Up/Down should operate that, but Space should start/stop playback, etc. Not sure it's possible to come up with a good design that feels both consistent and intuitive here, though.

Anyhow, there definitely needs to be thought given to the ramifications of change here and how to come up with a good design that suits all common use cases.

[shoogle]

@MarcSabatella, good points. How does the updated description sound?

[shoogle]

Currently, when a slider receives keyboard focus it gets this big ugly rectangle:

Not focussed	Focussed via keyboard

I don't think we should see this rectangle just because it was clicked on, so perhaps we need a separate "focussed via mouse" state like we do for text fields (see images in description), such as a thin blue outline around just the 'handle' part of the slider.

[irwir]

1. If this was a dialog (Mixer looks like one), the dialog was not disabled and it was clicked on - all further input should go to the dialog.
2. Nothing silently should go behind the scene - like altering notes in this case.
3. Using Left/Right arrow keys for vertical sliders is grossly counterintuitive.

[shoogle]

1. I don't think the Mixer looks anything like a dialog. Admittedly it can be undocked and moved to a different monitor, but that isn't the common use-case.
2. The note will still be highlighted in the score, so it shouldn't be too surprising if something happens to it. But we do need some kind of focus indicator on the slider (if not the ugly rectangle) so it's clear when the Mixer has focus.
3. I agree but that's a separate issue that can't be addressed until after #20056 is resolved. Up and Down are currently needed to navigate to the controls that Tab skips.

[irwir]

1. Mixer definitely does not look like tool palettes in Photoshop or Sibelius, even though technically it is a tool window.
2. Objection to the way you have edited my report. Quoting from previous text: Instead, key presses go directly to score and mangle it - change placement, notes and so on (especially nasty was that changes were going below the mixer dialog itself). Would you be able to see through the Mixer?

On the subject of standard keyboard shortcuts redefinition I have got something to say. Maybe later, and probably it would be in another bug report - where you explained reassignment of Tab key functions.