several issues with TextInput on devices

Bug Reports
1

Hey, testing with latest production and pre-release Fuse builds (6650, 6853), OSX. Issues only visible on devices, both running preview and production builds of the app.

Testcase:

<App>

    <TextInput ux:Name="MyInput" IsPassword="true" Height="50" Background="#88b" TextColor="#fff" HitTestMode="LocalBoundsAndChildren">
        <Panel Width="50" Dock="Right" HitTestMode="LocalBoundsAndChildren">
            <Text Alignment="Center" Value="Show" Color="#fff" />
            <Clicked>
                <Toggle Target="ShowPassword" />
            </Clicked>
        </Panel>
        <Clicked>
            <GiveFocus Target="MyInput" />
        </Clicked>
        <WhileTrue ux:Name="ShowPassword" Value="false">
            <Change MyInput.IsPassword="false" />
        </WhileTrue>
    </TextInput>

</App>

  1. iOS: when entering some text inside the TextInput, and then clicking the “Show” Panel, the IsPassword is being correctly set to true/false, however, the fonts are changed to a different typeface that looks like Times New Roman (https://www.dropbox.com/s/vap6sr4ytzngza9/Screenshot%202016-07-12%2009.47.03.png?dl=0). In addition to that, the caret is indented so as if there was a Tab or multiple spaces behind the entered string, although there clearly isn’t anything. This issue is also present on iOS simulators.

  2. Android: when repeatedly clicking the “Show” Panel, the caret gets put at the beginning of the entered string, while it should be left at the end. Applies both to when IsPassword is set to true and false.

2

Thanks for reporting, an internal issue have been created!

3

Toggeling IsPassword while editing text on iOS causes the TextInputs value to be cleard when going from IsPassword="false" to IsPassword="true". That behavior is the default in iOS and cannot be turned off without hacks in the inputhandling.

Maybe you should try another approach for making the Show Password feature (toggeling visibility on a <TextInput IsPassword="false" /> and <TextInput IsPassword="true" />.

The other issues will be fixed.

4

Hey @vegard, thanks for the reply!

I understand that the suggestion to use two TextInputs is to avoid the issue of caret being put in front of the entered content on iOS. That’s a really minor thing if the rest is fixed - especially the changing font face and weird indent.

Thing is, using two TextInputs for a single entity (password in this case) becomes somewhat complicated when you need to refer to them by ux:Name for example. Also, I haven’t tested this, but I suspect the suggested approach may have an undesired effect on the default focusing order upon TextInputActionTriggered.

I will for now run with this but a more simple alternative would be nice; that being said, the caret-at-the-front on iOS for a single edge case is not really a problem.

5

On second thoughts, I think the two textinputs approach might end up with the same problems on iOS when just toggeling IsPassword. Because the auto clear of the password happens if the IsPassword="true" textinput loses and gains focus. Which would happen if switching between two textinputs.

I think the easiest might be to just implement a native textinput with the workaround for the autoclear behavior.

6

Vegard Strand Lende wrote:

[…] implement a native textinput with the workaround for the autoclear behavior.

Any hints on the direction to do this right?

7

Implementing a UITextField subclass in ObjC and use that from foreign code. I realize that it might become tedious to do. Im gonna try to find some time this week to see if I can make a solution