Button shouldn't steal focus by default

[Sebastien Bacher]

The upstream Button component has "activeFocusOnPress: false" as its default, that doesn't seem the case for our component, it probably should.

Example

"MainView {
    height: 600
    width: 350

    Column {
        anchors {
            left: parent.left
            right: parent.right
        }
        TextInput {
            anchors {
                left: parent.left
                right: parent.right
            }
            focus: true
        }
        Button {
            text: "click"
            /* don't steal focus, activeFocusOnPress: false*/
        }
    }
}"

[Sebastien Bacher (seb128)]

Using that example, clicking on the button makes the keyboard focus move out of the textinput, using the upstream components it doesn't

[Tim Peeters (tpeeters)]

In most cases I think you want the button that you press to get focus. And if not, you can always set activeFocusOnPress to false.

[Zsombor Egri (zsombi)]

I disagree on that. It depends how you treat your app. I'm pretty surprised that QtQuick Controls' Button takes that as default, especially that those are mostly desktop components, and the focus handling there is exactly the opposite. No wonder why the QtQuick Gallery works badly on Ubuntu Touch.

[Sebastien Bacher (seb128)]

well, on a touch interface not stealing the focus makes sense no? if you are on a text entry and have the osk on screen (let's say in a messaging application), there is no reason that clicking "send" should move you out of the entry/close the osk, it means that to type another message you need to select the entry again, which is not ideal...

[Zsombor Egri (zsombi)]

Not really. On touch you steal the focus from a text input as well when typing on a button, right? So focus handling is the same as on desktop. More, we should not only think about touch, as that is limiting the convergence thinking.

[Sebastien Bacher (seb128)]

well, on click as well as desktop I would like the keyboard focus to still be in the text entry after clicking "send"... do you disagree with that? it doesn't seem to be an handy workflow, in a messaging app, to need to manual refocuss the text entry every time you send a message

[Zsombor Egri (zsombi)]

Yes, I disagree. It is case by case when you don't steal focus from text input, and that's app specific. We agreed with UX that every component - unless specified in app and use case - will steal focus from text input, thus will steal focus from each other.

[Cris Dywan (kalikiana)]

The most recent discussions around the focus UX are so far reaffirming that all components take focus on click out of the box, anything else is likely wrong, or otherwise a special case. Click/ touch needs to pass on focus so that subsequent keyboard navigation continues from that respective component. It also needs to steal focus to be able to hide the OSK which remains as long as any text input has focus. The only thing that is not given on click/touch is visual indication of focus - unless you use the keyboard to move around.

It's still possible that we find a case where this behavior needs to be more refined, but right now it's looking like the reported bug is making the wrong assumptions. You may want to validate your specific use cases with UX - in the bug report no concrete use case is given so I can't comment on that - but I'm happy to respond if you can be more specific.

[Pat McGowan (pat-mcgowan)]

is this incomplete or a won't fix?

[Cris Dywan (kalikiana)]

Considering there's still no concrete use case for the bug report, which is based on "we don't match upstream defaults, and design disagrees with good reason I'll consider this Won't Fix now.