Inconsistent Key Behavior on Android Keyboards with Password Protected TextField

[mikkdev]

Description: When using the Material TextField component with the IsPassword="True" attribute in version UraniumUI 2.8, keys not functioning correctly on Gboard and other Android keyboards.

Steps to Reproduce:

Open the application on an Android device running UraniumUI version 2.8. Navigate to a screen or form where a Material TextField with IsPassword="True" is present. Attempt to input text using Gboard or another Android keyboards. Observe that certain keys, such as backspace and some number keys, do not work as expected.

(Some Number Keys are working) (and others are not working)

Expected Behavior: When using Gboard or other Android keyboards, all keys should function properly, including backspace and number keys, when entering text into a Material TextField with IsPassword="True".

Actual Behavior: Certain keys, including backspace and some number keys, do not work as expected when entering text into a Material TextField with IsPassword="True" using Gboard or other Android keyboards.

[mikkdev]

Also the Keyboard="Numeric" doesnt work with the Textfield at all (all keys are not work here)

<material:TextField Title="{TemplateBinding Title}" Keyboard="Numeric">
     <material:TextField.Attachments>
         <Button
             StyleClass="TextButton"
             FontFamily="MaterialSharpSymbolsFilled"
             FontSize="20"
             Text="{x:Static symbols:MaterialSharp.Calendar_add_on}"
             Command="{TemplateBinding OpenCalendarCommand}" />
     </material:TextField.Attachments>
 </material:TextField>

[mikkdev]

It could be that this is a .Net MAUI bug. https://github.com/dotnet/maui/issues/21109 because it is the same in normal entry controls.

[mikkdev]

I apologize for the confusion caused by my recent bug report regarding the "Inconsistent Key Behavior on Android Keyboards with Password Protected TextField." Upon further investigation, I have realized that the issue stemmed from an error in my code. Specifically, I had overridden the DispatchKeyEvent method in my MainActivity, inadvertently blocking the Volume Keys functionality.

The root cause was that in the default case, I returned false instead of calling base.DispatchKeyEvent(keyEvent). This oversight resulted in the incorrect behavior observed in the app.

I sincerely apologize for any inconvenience or confusion this may have caused.

Thank you for your understanding.