Uno: [iOS][Android][Wasm] The space between the text and the clear button is too wide

[carlh98]

Current behavior

When you put the focus on the TextBoxErrorControl, the clear button appears and the text is push too far from the clear button.

Expected behavior

When you put the focus on the TextBoxErrorControl, the clear button appears and the text is moved next to the button

How to reproduce it (as minimally and precisely as possible)

Sample:
TextBoxAlignmentIssueSample.zip

Environment

Nuget Package:
Uno.UI

Package Version(s):
2.1.0-dev.509

Affected platform(s):

• [x] iOS
• [x] Android
• [x] WebAssembly
• [ ] WebAssembly renderers for Xamarin.Forms
• [ ] macOS
• [ ] Windows
• [ ] Build tasks
• [ ] Solution Templates

Visual Studio:

• [ ] 2017 (version: )
• [ ] 2019 (version: )
• [ ] for Mac (version: )

Relevant plugins:

• [ ] Resharper (version: )

Anything else we need to know?

[carlh98]

Framework work item:
https://dev.azure.com/nventive/Umbrella/_workitems/edit/169759

Azure DevOps Services | Sign In

[carldebilly]

@carlh98
It has not been tested yet, but the package Uno.UI v2.1.0-dev.1090 contains fixes related to this issue and it should be tested again on this version.

[carlh98]

@carldebilly
There's a new regression for the sample TextBoxAlignmentIssueSample.zip with Uno.UI 2.1.0-dev.1097, the control is present in the View Hierarchy but not visible in the app

[carldebilly]

PR #2679 has been merged, producing Uno.UI v2.1.0-dev.1371 which should be available soon on Nuget there: https://www.nuget.org/packages/Uno.UI/2.1.0-dev.1371. This issue could be fixed by those changes and need to be tested again with this version of Uno.UI.

Uno.UI 2.1.0-dev.1371

Build Mobile, Desktop and WebAssembly apps with C# and XAML. Today. Open source and professionally supported.

[carlh98]

@carldebilly
With Uno.UI 2.1.0-dev.1371:
(Regression) In iOS, the TextBoxErrorControl does not appear on screen, you can click on the TextBoxErrorControl area where it's supposed to appear to show the tactile keyboard
(Same) In Android and Wasm it's the same as 2.1.0-dev.509

[carldebilly]

Investigations

I found the cause of the problem: it's a resource issue.

==> May be fixed by PR https://github.com/unoplatform/uno/pull/1766. @davidjohnoliver ?

Explanation

1. There's a Default Style on <Button> defined this way:
   xml <Style x:Key="DefaultButtonStyle" TargetType="Button"> <Setter Property="MinWidth" Value="128" /> </Style> <Style TargetType="Button" BasedOn="{StaticResource DefaultButtonStyle}" />
   (more properties are defined... but they are not relevant to this bug)
2. The control is defined this way...
   xml <Button Style="{StaticResource DeleteButtonStyle}" Width="24" Padding="4,0,0,0" HorizontalAlignment="Right" />
3. The DeleteButtonStyle is defined like that...
   xml <Style x:Key="DeleteButtonStyle" TargetType="Button"> <Setter Property="Width" Value="40" /> <Setter Property="Padding" Value="0" /> <Setter Property="Margin" Value="0" /> </Style>
   On UWP, the result control will get a MinWidth of 0... like if the DeleteButtonStyle were not having an implicit BaseOn on the default style, which is the case on Uno Platform. Actually, on Uno, the <Button> will have a MinWidth=128, causing the reported bug.

Why it's a regression

This wasn't happening before because MinWidth, MaxWidth, MinHeight & MaxHeight were not properly calculated in the past.

Workaround

Add a setter for MinWidth on DeleteButtonStyle to override the default one coming from DefaultButtonStyle.