Button shouldn't steal focus by default

Bug #1368390 reported by Sebastien Bacher on 2014-09-11
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Canonical System Image
High
Zoltan Balogh
ubuntu-ui-toolkit (Ubuntu)
High
Christian Dywan
ubuntu-ui-toolkit (Ubuntu RTM)
High
Christian Dywan

Bug Description

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) wrote :

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) wrote :

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.

Changed in ubuntu-ui-toolkit:
assignee: nobody → Zsombor Egri (zsombi)
importance: Undecided → Medium
status: New → Incomplete
Zsombor Egri (zsombi) wrote :

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.

Changed in ubuntu-ui-toolkit:
importance: Medium → Wishlist
status: Incomplete → Triaged
Sebastien Bacher (seb128) wrote :

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) wrote :

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) wrote :

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) wrote :

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.

Zoltan Balogh (bzoltan) on 2014-11-24
Changed in ubuntu-ui-toolkit (Ubuntu):
assignee: nobody → Zsombor Egri (zsombi)
importance: Undecided → Wishlist
status: New → Triaged
Changed in ubuntu-ui-toolkit (Ubuntu):
assignee: Zsombor Egri (zsombi) → Christian Dywan (kalikiana)
Changed in ubuntu-ui-toolkit (Ubuntu):
importance: Wishlist → High
Changed in ubuntu-ui-toolkit (Ubuntu):
status: Triaged → In Progress
Changed in ubuntu-ui-toolkit:
assignee: Zsombor Egri (zsombi) → nobody
Zoltan Balogh (bzoltan) on 2015-12-08
no longer affects: ubuntu-ui-toolkit
Changed in canonical-devices-system-image:
assignee: nobody → Zoltan Balogh (bzoltan)
milestone: none → ww08-2016
Changed in canonical-devices-system-image:
status: New → In Progress
importance: Undecided → High
Christian Dywan (kalikiana) wrote :

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.

Changed in canonical-devices-system-image:
status: In Progress → Incomplete
Zsombor Egri (zsombi) on 2016-03-07
Changed in ubuntu-ui-toolkit (Ubuntu):
status: In Progress → Incomplete
Changed in ubuntu-ui-toolkit (Ubuntu RTM):
status: New → Incomplete
Changed in canonical-devices-system-image:
milestone: ww08-2016 → 11
Changed in ubuntu-ui-toolkit (Ubuntu RTM):
assignee: nobody → Christian Dywan (kalikiana)
importance: Undecided → High
Pat McGowan (pat-mcgowan) wrote :

is this incomplete or a won't fix?

Changed in canonical-devices-system-image:
milestone: 11 → backlog
Christian Dywan (kalikiana) wrote :

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.

Changed in ubuntu-ui-toolkit (Ubuntu):
status: Incomplete → Invalid
Changed in ubuntu-ui-toolkit (Ubuntu RTM):
status: Incomplete → Invalid
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers

Related blueprints