hintStyle of InputDecorationTheme not correctly applied

[fhuonder]

Hi all,

When having a custom theme with a custom InputDecorationTheme, like

new ThemeData(
    //...
    inputDecorationTheme: const InputDecorationTheme(
      focusedBorder: UnderlineInputBorder(borderSide: BorderSide(color: Colors.red)),
      enabledBorder: UnderlineInputBorder(borderSide: BorderSide(color: Colors.yellow)),
      labelStyle: TextStyle(color: Colors.yellow),
      hintStyle: TextStyle(color: Colors.red),
    ));

my expectation, according to the documentation of the hintStyle property, is that the label text of a focused text field gets the color of the hint style. Unfortunately it stays the color of the labelStyle. When no custom InputDecorationTheme is in use it works.

---

With custom theme (expectation: in the focused case the text 'Place' should be red):

---

Without custom theme (where primary color is cyan and accent color is purple):

---

Is the configuration wrong or is it really a bug?

Regards,
Florian

[HansMuller]

The InputDecorator's hintStyle appears to be initialized correctly from the InputDecorationTheme in this test case: https://gist.github.com/HansMuller/f41427548f2357931d48c9becbc51e9b

If you can provide a test case that fails, I'll be happy to look into it.

[fhuonder]

Hi Hans,

The problem occurs when you use labelText (instead of hintText) of the InputDecoration.

new TextField(
    decoration: new InputDecoration(labelText: "Hello 1"),
)

On focus the text moves upwards and should adopt the hintStyle, according to the documentation of the InputDecorationTheme's hintStyle (it says: Also used for the [labelText] when the [labelText] is displayed on top of the input field (i.e., at the same location on the screen where text may be entered in the input field).).

Hope this helps.

Regards,
Florian

[HansMuller]

Aha! You are correct, the implementation does not match the documentation. And we're not currently testing the floating label's text style.

Although it's easy enough to "fix" this issue, it may just be a documentation bug. On the face of it, there doesn't seem to be any reason for the label's style to change when it "floats". It does change color if errorText is (also) specified or if the input decorator is disabled.

@willlarche - If a textfield's hint and label styles are different, should the label's style morph to the hint style when the textfield gets the focus and the label floats (moves upwards)?

[willlarche]

Just to make sure I understand the issue:
Given:

• There is no hint text.
• There is label text.
• There is styles for both label and hint.
  Expectation:
• When the label is down, it's label style
• When the label is up, it's hint style
  Result:
• Always label style.

Question:

• Should they morph back and forth?

[HansMuller]

Right, if the text field is displaying a label, should the label's style morph from the specified label-style to the hint-style when it moves up (upon focus) or back down again upon losing focus.

[willlarche]

I think, Hans, that your documentation didn't mean floating but being inline (not floating).

Also used for the [labelText] when the [labelText] is displayed on top of the input field (i.e., at the same location on the screen where text may be entered in the input field)

In which case that means use the hint style when it's not floating and the label style when it is.

Certainly you shouldn't use the hint style when floating, period. But we should support having 2 different styles for the label: one for floating and one for not-floating.

The other platforms just do color and size since they can't animate font or weight changes. If Flutter can animate font or weight changes, it would be cool to allow that interpolation.

Incidentally, this underline style of text field is deprecated. Consider adding a filled background like you find in the current guidelines. Our extensive UX research shows people are vastly more likely to properly interact with a text field that defines its touchable space than the legacy designs!

[fhuonder]

So...

• The label should not morph into the hint style when it's floating (goes upwards on selection of the text field). That figures.
• Is the default behavior wrong? In case no InputDecorationTheme is defined the label morphs when it floats (see my print screens). Is this a bug or is there another style applied in that case?
• Should the documentation be adapted so that it is more clear?
• What about the point that the style is deprecated?

[shinyford]

I believe this is still wrong (and that there was a misunderstanding the thread above).

The documentation states:

GIVEN

• hintStyle is null
• labelText, labelStyle and hintStyle are not null

THEN

• when the input text is empty, the label is positioned inside the input box and takes the hintStyle
• when the input text is not empty, the label is positioned above the input box and takes the labelStyle

(The discussion above had it the other way around: labelStyle when raised, hintStyle when in the input box.)

This makes sense to me, but currently is not what happens. Is there likely to be a fix? Many thanks.

[TahaTesser]

Issue still exist

flutter doctor -v

[✓] Flutter (Channel dev, v1.18.0-6.0.pre, on Mac OS X 10.15.4 19E287, locale
    en-GB)
    • Flutter version 1.18.0-6.0.pre at /Users/taha/Code/flutter_dev
    • Framework revision 84c84fb249 (31 hours ago), 2020-04-20 21:35:01 -0400
    • Engine revision 2bde4f0ae4
    • Dart version 2.9.0 (build 2.9.0-1.0.dev a12c36dd97)
 
[✓] Android toolchain - develop for Android devices (Android SDK version 29.0.3)
    • Android SDK at /Users/taha/Code/sdk
    • Platform android-29, build-tools 29.0.3
    • ANDROID_HOME = /Users/taha/Code/sdk
    • Java binary at: /Applications/Android
      Studio.app/Contents/jre/jdk/Contents/Home/bin/java
    • Java version OpenJDK Runtime Environment (build
      1.8.0_212-release-1586-b4-5784211)
    • All Android licenses accepted.
[✓] Xcode - develop for iOS and macOS (Xcode 11.4.1)
    • Xcode at /Applications/Xcode.app/Contents/Developer
    • Xcode 11.4.1, Build version 11E503a
    • CocoaPods version 1.9.1
[✓] Chrome - develop for the web
    • Chrome at /Applications/Google Chrome.app/Contents/MacOS/Google Chrome
[✓] Android Studio (version 3.6)
    • Android Studio at /Applications/Android Studio.app/Contents
    • Flutter plugin version 45.1.1
    • Dart plugin version 192.7761
    • Java version OpenJDK Runtime Environment (build
      1.8.0_212-release-1586-b4-5784211)
[✓] VS Code (version 1.44.2)
    • VS Code at /Applications/Visual Studio Code.app/Contents
    • Flutter extension version 3.9.1
[✓] Connected device (4 available)
    • SM M305F   • 32003c30dc19668f • android-arm64  • Android 10 (API 29)
    • macOS      • macOS            • darwin-x64     • Mac OS X 10.15.4 19E287
    • Chrome     • chrome           • web-javascript • Google Chrome
      81.0.4044.113
    • Web Server • web-server       • web-javascript • Flutter Tools
• No issues found!