Skip to content

Conversation

@mpcomplete
Copy link
Contributor

Fixes #6603

@Hixie
Copy link
Contributor

Hixie commented Nov 4, 2016

This breaks autofocus, right?

LGTM, ideally with a test, if breaking autofocus is intentional.

Now that we only want to show the keyboard in response to use action, though, maybe we should just literally do it onTap, rather than messing with build and so on.

@mpcomplete
Copy link
Contributor Author

The reason I did it in 2 steps is this comment: https://github.com/flutter/flutter/blob/master/packages/flutter/lib/src/widgets/editable.dart#L301 . This implies that attempting to acquire focus may fail.

I suppose it would break autofocus - or at least, prevent the keyboard from showing for an autofocused widget, until you tap it. I'm not sure what the correct behavior is. I don't know of any examples of autofocused text fields in other material apps.

@Hixie
Copy link
Contributor

Hixie commented Nov 7, 2016

Yeah maybe we should just rip the autofocus idea out entirely.

You're right about the showing the keyboard after getting focus thing. Not sure what we can really do to make that better...

@mpcomplete mpcomplete merged commit b9bff6a into flutter:master Nov 8, 2016
@mpcomplete mpcomplete deleted the keyboard branch November 8, 2016 19:14
@Hixie
Copy link
Contributor

Hixie commented Nov 8, 2016

This shouldn't have landed, since Travis was red for this PR. Please don't land PRs unless Travis is green and the waterfall is showing no problems.

@github-actions github-actions bot locked as resolved and limited conversation to collaborators Aug 14, 2021
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Input reopens keyboard after user interacts with a form element other than Input

2 participants