Slider: Do not grab focus on tap event

[dweymouth]

Description:

Do not focus the slider if it is interacted with by a tap event. This is inconsistent with other widgets (button, etc) which only become focused by the focus manager with the tab key. Entry of course grabs focus when tapped, but this is because Entry must be interacted with the keyboard. Tapping or dragging to change a slider value does not imply that the user wants to further control the slider afterward with the keyboard.

Edit: Looks like check keeps focus after tap, and button does not. I think none but Entry should keep focus after a tap, but whichever way we go we should make it consistent

Fixes #4369

Checklist:

• Tests included.
• Lint and formatter run with no errors.
• Tests all pass.

[coveralls]

coverage: 65.081% (+0.008%) from 65.073%
when pulling 5632be5 on dweymouth:slider-unfocus
into e250829 on fyne-io:develop.

[Jacalz]

Thanks. I think this makes sense but I'd like to hear someone else's opinion as well.

[andydotxyz]

Agreed. Not sure about check, but would be happy at this time to say Entry is the only one that keeps focus as that is what we seem to have mostly done.

[Jacalz]

It might be the case that Radio also keeps focus?

[dozn]

Anything you touch should have focus, but that focus (outside of specific widgets) should not be visible until either hotkeys ((Shift-)TAB) are hit (in which case it will jump to the previous/next widget).

This is also the way browsers do it.

[dweymouth]

Anything you touch should have focus, but that focus (outside of specific widgets) should not be visible until either hotkeys ((Shift-)TAB) are hit (in which case it will jump to the previous/next widget).

This is also the way browsers do it.

I think what's happening in that case is it's changing what the next-to-focus widget will be without actually giving any widget focus until (Shift-)TAB is hit.

[andydotxyz]

should not be visible until either hotkeys ((Shift-)TAB) are hit (in which case it will jump to the previous/next widget).

I don't think we should have multiple states for focus. If something is focused (can get key signals) then that should be visible.

This is also the way browsers do it.

I could not replicate it with safari - the keyboard support seems less than intuitive (only links got focus, not form elements).

The discussion leads me to think that dragging a slider does not give it focus (as you're performing the action, not just switching widget) though it leaves check and radio up for debate. Button too will not take focus just because it's tapped, as the action of tapping is the whole interaction. So maybe checking a check/radio on tap should not give it focus? (Leading back to the idea that Entry is the only one - plus derivatives).

[Jacalz]

So maybe checking a check/radio on tap should not give it focus? (Leading back to the idea that Entry is the only one - plus derivatives).

I think that might be a good idea

[dozn]

Your action of interacting with an element gives it focus, but does not visually display it as such until the keyboard is used.

Here are my tests on on Chromium/Firefox/Edge (might have to enable audio) showing this is the case unless continued input is expected (input fields):
Sliders https://imgur.com/sIwJqvx
Checkboxes https://imgur.com/BTLlEJc
Buttons https://imgur.com/4nR9Xvx
Select https://imgur.com/Tr6G39W
Radio https://imgur.com/CA6qcYx
Audio https://imgur.com/1eF1MsY (video element performed the same)
Number input https://imgur.com/aq6u92P

This makes sense as your "focus" is currently on the last thing you've interacted with, but because such a low percentage of people would be using both mouse and keyboard for non-entry fields, they hide the visual focus indicator until a keyboard button is hit.

I agree with this behaviour as the vast majority of users don't need a constant reminder to know what the last thing they clicked on was (besides entry boxes, as you're expected to continue interacting with it using the keyboard, and need to know where your input will end up!), and when you do end up using the keyboard, it should apply to the last thing you touched.

It would be incredibly jarring to be working at the bottom of an application, hit TAB, then have the focus jump to the top of the application.

[Jacalz]

I think you might be right about that. It seems like the more anticipated change from the user. Maybe our buttons ought to keep the focus?

If that's the case, maybe we ought to have a better API than doing this?

	driver := fyne.CurrentApp().Driver()
	if !s.focused && !driver.Device().IsMobile() {
		impl := s.super()

		if c := driver.CanvasForObject(impl); c != nil {
			c.Focus(impl.(fyne.Focusable))
		}
	}

[andydotxyz]

It would be incredibly jarring to be working at the bottom of an application, hit TAB, then have the focus jump to the top of the application.

I agree with this statement, but in reference to my prior post this is actually what happens on Safari (macOS). I need a better browser to test against ;).

[andydotxyz]

What does the discussion mean to the original post? Should the focus be "grabbed" after all but not indicated?
I'm struggling to figure out what the desirable outcome is here. Becoming more consistent is what we want - does this PR help us to do that whilst we have a separate design level discussion?

[Jacalz]

I understand the discussion here as saying that this PR is doing the exact opposite. We no longer mark the slider widget as the currently focused object when clicking on it.

[andydotxyz]

As discussed on the call today this requires some exploration to determine what the right overall approach is.
Once established we can work to be consistent with that and this PR may or may not fit.

[dweymouth]

We seem to be moving toward all input widgets grabbing focus when tapped so closing this

[andydotxyz]

Hmm, we are currently working on consistency.
I am still interested in the "next to focus" idea where we don't immediately set focus but instead wait for a keyboard event before marking an item as focused. This might avoid all the mobile-specific handling to skip the focus event as well, so could be cleaner in the long run.