Bug: Problems with ScrollViewer, TextBox and focus

[benstevens48]

Edit - the first case mentioned below, about the text box not losing focus when cling outside, should probably be discussed in a separate issue. Use this issue to track the second bug, which involves the delete button.

Describe the bug It's possible these issues have been resolved in the new ScrollViewer control, but I am using the OS built-in version.

Create a very simple page like this with a scroll viewer and text box.

<Page x:Class="DeleteButtonSample.MainPage" xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation" xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml" xmlns:local="using:DeleteButtonSample" Background="{ThemeResource ApplicationPageBackgroundThemeBrush}">
    <Grid>
        <ScrollViewer VerticalScrollMode="Auto" VerticalScrollBarVisibility="Auto" HorizontalScrollMode="Disabled" HorizontalScrollBarVisibility="Hidden">
            <StackPanel VerticalAlignment="Top">
                <Button Content="Dummy"></Button>
                <TextBox x:Name="textBox" Width="200" HorizontalAlignment="Left" GotFocus="textBox_GotFocus" LostFocus="textBox_LostFocus"></TextBox>
                <TextBlock x:Name="textBlock"></TextBlock>
            </StackPanel>
        </ScrollViewer>
    </Grid>
</Page>

using Windows.UI.Xaml;
using Windows.UI.Xaml.Controls;

namespace DeleteButtonSample
{
    public sealed partial class MainPage : Page
    {
        public MainPage()
        {
            this.InitializeComponent();
        }

        private void textBox_GotFocus(object sender, RoutedEventArgs e) {
            System.Diagnostics.Debug.WriteLine("got focus");
            textBlock.Text = "Has focus";
        }

        private void textBox_LostFocus(object sender, RoutedEventArgs e) {
            System.Diagnostics.Debug.WriteLine("lost focus");
            textBlock.Text = "Does not have focus";
        }
    }
}

Run it, click in and out of the text box - you will see the text block text update to "Has focus" and "Does not have focus". However, here is the first bug.

Comment out the Dummy button. Now repeat clicking in and out of the text box. Note the text box doesn't lose focus. This means the very common pattern update/save on lose focus doesn't work because the text box doesn't lose focus.

Now the next issue is more delicate. Put the Dummy button back in. Run the app. Type some text in the text box and click out of it so it loses focus. Now click in it again once, click and drag to highlight some text without releasing the mouse button, move the cursor exactly over the text box delete button, then release. You should see that the text box loses focus. This is also an issue for save/update on lose focus as the save can happen unexpectedly for the user. Note you may need several attempts to get this behavior.

Expected behavior In the first case, clicking outside the textbox should cause it to lose focus. In the second case, releasing the mouse when selecting text in the text box should not cause it to lose focus.

Version Info Not using WinUI, using the built-in OS version.

Windows app type:	UWP	Win32
Yes

Windows 10 version	Saw the problem?
Insider Build (xxxxx)
May 2020 Update (19041)
November 2019 Update (18363)	Yes
May 2019 Update (18362)
October 2018 Update (17763)
April 2018 Update (17134)
Fall Creators Update (16299)
Creators Update (15063)

Device form factor	Saw the problem?
Desktop	Yes
Xbox
Surface Hub
IoT

[YuliKl]

Comment out the Dummy button. Now repeat clicking in and out of the text box. Note the text box doesn't lose focus. This means the very common pattern update/save on lose focus doesn't work because the text box doesn't lose focus.

The TextBox isn't losing focus because there are no other focusable elements on this page. Focus has nowhere else to go, so can't be lost.

Type some text in the text box and click out of it so it loses focus. Now click in it again once, click and drag to highlight some text without releasing the mouse button, move the cursor exactly over the text box delete button, then release. You should see that the text box loses focus.

@benstevens48 are you suggesting that releasing on the delete button should or should not cause the TextBox to lose focus? I would expect focus to remain on the TextBox because the delete button isn't a focusable element, not sure whether you agree. Edit: re-read your "expected behavior" and we agree.

Please update the bug to talk only about the second issue as I believe the first issue is by design.

[benstevens48]

@YuliKl - no the first issue is a bug or at least a design flaw. If you don't have the scroll viewer then the text box will lose focus when you click outside. If you think about what the user expects then you want it to lose focus - e.g. think about renaming a file in File Explorer or Visual Studio. At the moment one has to put in an invisible button at the top of the scroll viewer - is that really the best solution? Edit: I can see that there might be an argument both ways here. But I find that I have to put in an invisible button at the top of every scroll viewer which contains input elements. I wonder if there is a better solution.

Yes, focus should remain on the text box. At the moment it loses focus. (Keep the dummy button in for this test, and follow the instructions exactly. It can take a few tries to reproduce it).

[benstevens48]

Upon further reflection, I've decided that I don't mind the first issue so much, where the text box does not lose focus when clicking outside, because I can work around it by using an invisible button and at least that gives me some degree of control. This isn't completely ideal though, and the WinUI team might want to have an internal discussion about it and/or open another issue. I've made a note that this issue should just track the second bug involving the delete button.

[chrisglein]

It does seem like the down click would grant focus although maybe the click release is what's triggering that? (as in did this thing every get focus at all during this transaction?) I haven't seen anything here to indicate that this is a regression. So that affects the relative priority of getting a fix for WinUI3 (which would have the same behavior as in the OS).

[benstevens48]

This needs checking in WinUI3.

[JoeTomkinson]

This does seem to be an issue still in WinUI3 if there are no other focusable items within a ScrollViewr, or ScrollView control, the TextBox will gain focus when other controls are clicked off of.

For example I have a page with 5 NumberBoxes and one Textbox at the top. If you click off of the 5th NumberBox, the TextBox will gain focus and scroll back into view. It creates a pretty poor user experience and the TextBox should not really gain focus.

Definately seems like a bug to me because what is the design decision that would warrant that particular behaviour?

[MartyIX]

Not sure if this bug is the same one as I reported here https://github.com/dotnet/maui/issues/19733#issue-2069109797 but if it is then the bug can be visually demonstrated as:

[fabianoriccardi]

@MartyIX exactly what I'm experiencing with WASDK v1.5.4 😒

[MartyIX]

It is fixed in 1.6-experimental-1 according to: https://github.com/microsoft/microsoft-ui-xaml/issues/597#issuecomment-2040254885 if I'm not mistaken.

So one way would be to try to bump to that version in your app. But I don't think it is as easy as bumping 1.5.x series in MAUI.

[fabianoriccardi]

Thanks for the info, I have tried to update to 1.6 but I get a runtime error (the CommunityToolkit is involved). I will continue the test in next days...

[HO-COOH]

@MartyIX This seems to be fixed in WASDK 1.6, but it brought another issue with it. Now the textbox is not losing focus 😂. See the above mention.

[MartyIX]

I tried a nightly version of .NET MAUI 9 and this bug still seems to be present. Hopefully, I'm wrong. I'll retest with .NET 9 MAUI GA.