[Bug] Label displays an incorrect text when AutomationProperties.Name was set

[holecekp]

Description

A Label displays incorrect text when its Text property is an empty string, if AutomationProperties.Name has been set for this Label in the past.

This might be connected with the bug #7875.

Steps to Reproduce

I have created a simple example that demonstrates the bug behavior. Basically, there is an Entry and a Label that displays the text from the Entry in the uppercase. The AutomationProperties.Name are also set on the Label (for simplicity, the same value as for the Text property is used).

LabelBug.zip

1. Enter "a" in the Entry.
2. The label shows a red "A", which is OK.
3. Delete text from the Entry.
4. The label still shows the "A" but in gray color.
5. Enter "b" in the Entry.
6. The label shows a red "B", which is OK.
7. Delete text from the Entry.
8. The label displays a grey "A". It seems that Label somehow remembers the first non-whitespace AutomationProperties.Name and displays it in gray color when there is no other text to be displayed.

The attached example also contains button which can be used to verify that both Text and AutomationProperties.Name are empty. However, the mentioned gray text is still displayed on the screen.

Expected Behavior

When the Text property and AutomationProperties.Name are set to empty string, the Label should not display any text on the screen.

Actual Behavior

The label displays former AutomationProperties.Name in gray color on the screen.

Basic Information

• Version with issue: Xamarin.Forms 4.4.0.991537
• IDE: Visual Studio 2019
• Platform Target Frameworks: Android: 9.0
• Affected Devices: Bug appears both in emulator and the physical device (Xiaomi Mi A2 Lite)

[WayaFlyfeather]

I can confirm this happens.

I can also say something about what happens, but I don't feel I know the code well enough to make a PR; there may be reasons for the code doing what it does.

First off, the reason the first entered text remains as a "ghost" are these lines.

Here defaultHint is set to whatever is in textView.Hint. But defaultHint is passed by reference, so this becomes permanent. And once set, is never overwritten - because, it is only changed if it is null. And later, if the current content does not make a proper hint-text (is whitespace or null), the defaultHint is used. So, everytime the content is whitespace or null, the first non-null hint is used - 'A' if we follow the steps to reproduce.

But even if you don't set defaultHint, but use a local variable for the logic, it doesn't work; when the content becomes whitespace, the previous content is used instead; the "ghost" may become 'B', but a ghost is still around.

The simplest thing to do seems to me to be to simply delete lines 145-148; this will set the hint from the current content, if any, otherwise use any defaultHint; and not try to save a previous textView.Hint. And this works fine for this issue, but there may be a reasoning for the current way of doing things that I am not aware of.

Otherwise the best way would probably be to differentiate between if content is null or whitespace, so that the hint from content is only not used if it is truly null. This, however also requires code changes in the ConcatenateNameAndHelpText-method, as doesn't differentiate between null and whitespace either.

(I'd be happy to make a PR with one of these solutions, but as I mentioned, I don't know if this will have repercussions I'm not aware of. But I hope this may at least save somebody some time investigating.)

[hartez]

I sort of suspect this might be a bug with the Android Entry TextChanged event.

[PureWeen]

Please try SemanticEffect on the XCT xamarin/XamarinCommunityToolkit#1240

The behavior of SemanticEffect is much more accurate