CupertinoSearchTextField placeholder should resize as the text field resizes instead of being closed over

[victorsanni]

Use case

If a CupertinoSearchTextField is made to resize (for example, in a scroll view), the placeholder text should move as the search bar resizes instead of being closed over.

Native Search Bar

https://github.com/user-attachments/assets/39372e3d-e59a-43c7-a94b-b71038b1ee6e

Flutter CupertinoSearchTextField

https://github.com/user-attachments/assets/9d3c59a3-5fda-47b2-993b-cc05b9eba596

CupertinoSearchTextField uses CupertinoTextField behind the scenes, so this will probably require changes in CupertinoTextField:

Flutter CupertinoTextField

https://github.com/user-attachments/assets/d6b97b31-8f6e-46e0-bf62-43c3eace252b

Proposal

Match the native text field/search bar resizing behavior.

[victorsanni]

Material TextField is closer to this expected behavior. When the textfield resizes, the placeholder text also moves:

https://github.com/user-attachments/assets/0d9c63f2-b9d5-4616-9b04-b1a1b03bf2ee

[victorsanni]

I saw this in CupertinoTextField's implementation:

https://github.com/flutter/flutter/blob/6dc88205de90716d385ee9e5e74b7aa9ebbc9584/packages/flutter/lib/src/cupertino/text_field.dart#L1216-L1237

[justinmc]

Just wanted to chime in saying that this looks like something that would be nice to put in CupertinoTextField itself, if possible. At least behind a flag.

[victorsanni]

On further exploration, I think CupertinoTextField.padding is causing the issue. When the text field resizes, the padding (sort of) has priority over the placeholder/editable text on who should remain in the field the longest.

I tried wrapping the placeholder/editable text stack in a LayoutBuilder, extracting the padding's vertical component and using that to set the height of the stack while aligning the placeholder/editable text to the center (so that on resize, that alignment is maintained, moving them as desired). This seems to work but a lot of tests are failing as a result.

[github-actions[bot]]

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 -v and a minimal reproduction of the issue.