Repository navigation
Discrepancy on TextFormField focus change between desktop and web #58207
Description
Noticed an difference between how desktop and web handles TextFormField focus. This is very similar to this issue (#32433), but wanted to give a clear example of the problem.
Can't really prescribe what should done, since it I kind of see the pros/cons of both approaches :P
But think they should be the same for consistency at least, so we could use the same approach when handling in apps.
Thanks!
import 'package:flutter/material.dart';
void main() {
runApp(MyApp());
}
class MyApp extends StatelessWidget {
@override
Widget build(BuildContext context) {
return MaterialApp(
title: 'Flutter Demo',
theme: ThemeData(
primarySwatch: Colors.blue,
visualDensity: VisualDensity.adaptivePlatformDensity,
),
home: MyHomePage(title: 'Flutter Demo Home Page'),
);
}
}
class MyHomePage extends StatefulWidget {
MyHomePage({Key key, this.title}) : super(key: key);
final String title;
@override
_MyHomePageState createState() => _MyHomePageState();
}
class _MyHomePageState extends State<MyHomePage> {
FocusNode _focusNode;
void _handleBtnClick() {
print("Button clicked!");
}
@override
void initState() {
_focusNode = FocusNode(
canRequestFocus: true,
);
_focusNode.addListener(() => print("FocusNode changed. Top text input HasFocus?: ${_focusNode.hasFocus}"));
super.initState();
}
@override
Widget build(BuildContext context) {
return Scaffold(
appBar: AppBar(
title: Text(widget.title),
),
body: Center(
child: Column(
crossAxisAlignment: CrossAxisAlignment.start,
children: <Widget>[
Container(
padding: EdgeInsets.all(24),
child: TextFormField(
focusNode: _focusNode,
),
),
Container(
padding: EdgeInsets.all(24),
child: TextFormField(),
),
Container(
padding: EdgeInsets.all(24),
child: Column(
crossAxisAlignment: CrossAxisAlignment.start,
children: [
Text("Demo to show discrepancy in focus between TextFormField in desktop vs web"),
Text("\n1) Click on the top-most TextFormField above, so you can see the text carat"),
Text("2) Click the action button on bottom right"),
Text("3) Check the console"),
Text("\nNotice on desktop: \n -Focus does not change, text carat stays put"),
Text("\nNotice on web: \n -Focus changes (hasFocus = false), loses text carat"),
Text(
"\nNot sure what the expected/best behavior should be, but just want to highlight the difference"),
Text(
"\nNote that on desktop & web, clicking the bottom-most text input will change the focus from the top, which is expected"),
],
),
),
],
),
),
floatingActionButton: FloatingActionButton(
onPressed: _handleBtnClick,
tooltip: 'Click me',
child: Icon(Icons.add),
),
);
}
}
Activity
stuartmorgan-g commentedon May 29, 2020
Desktop platforms don't necessarily have the same conventions as the web, so doing the same thing on every platform would be inconsistent with the platforms the applications are running on. On macOS, for instance, clicking on a non-control area of an application window will not have any effect on focus.
esDotDev commentedon May 29, 2020
imo, it should generally be up to the developer to respect or ignore platform conventions, without the framework deciding it knows best in various circumstances. This leads to a much larger testing footprint when you build in variable behavior like this, and many wasted hours testing and debugging platform-specific intricacies.
In one scenario, I know exactly how my app will behave, on every platform, it will do exactly as I ask, and I can add in simple, specific logic to respect platform conventions if I choose.
In another, I have no clue, without pouring through source code, what the minute differences are on every platform, and I have to actually test every single platform on a regular basis, which defeats much of the efficiency gains you get from a cross-platform framework.
How is a single developer expected to regularly test on Linux, Windows, OSX, Android and iOS, and maintain any development speed at all?
Consistency should be king here, especially across Web-Running-On-Desktop and Desktop.
For example, if a Developer decides he wants to support the 'convention' of Clickable-background on Web, and not on Desktop, it's a couple lines of code, and he can add it anytime he wants.
If the framework decides to do it, developer either is not even aware he has a bug, has to test on every single possible platform to notice the bug, and then has to figure out how to fight the framework to just get back to the non-opinionated behavior he is looking for.
nturgut commentedon Jun 6, 2020
@eddie-at-work Thanks for filing the issue. We changed our approach this week.
Previously, Flutter for Web behaved like a web page. If user click on an area other than the input field itself, the input field is blurred, thus the connection is closed.
We changed this behavior for Desktop Browsers. Now only, pressing enter, tab changes the focus of the input fields. Therefore clicking on a button as you suggested also won't change the focus.
Please check the PR: flutter-team-archive/engine#18743
There is another issue with a longer discussion: #49785 Please also have a look there.
github-actions commentedon Aug 20, 2021
This thread has been automatically locked since there has not been any recent activity after it was closed. If you are still experiencing a similar issue, please open a new bug, including the output of
flutter doctor -vand a minimal reproduction of the issue.