Win32 picking APIs causes the UI to freeze after dialog closes

[AmelBawa-msft]

Describe the bug

In Dev Home, we are using the Win32 picker APIs as suggested in this doc to workaround the dialog exception issue when running the application in elevated mode. I noticed that using this API sometimes causes the application UI to become non-responsive after the file picker dialog is closed. I am able to repro on an empty WinUI application (details in next section).

Steps to reproduce the bug

XAML

    <Grid Background="Transparent">
        <Grid.RowDefinitions>
            <RowDefinition Height="*"/>
            <RowDefinition Height="auto"/>
        </Grid.RowDefinitions>
        <Button x:Name="myButton" Margin="50" Click="myButton_Click">Click Me</Button>
        <CheckBox Margin="50" Grid.Row="1" Content="Checkbox" />
    </Grid>

XAML.CS

    private async void myButton_Click(object sender, RoutedEventArgs e)
    {
        await OpenFilePickerAsync(this, ("*.yaml", "YAML FILES"));
    }

    public static async Task<StorageFile?> OpenFilePickerAsync(Window window, params (string Type, string Name)[] filters)
    {
        try
        {
            string fileName;

            // Original code reference: https://learn.microsoft.com/uwp/api/windows.storage.pickers.filesavepicker?view=winrt-22621#in-a-desktop-app-that-requires-elevation
            // Github issue: https://github.com/microsoft/WindowsAppSDK/issues/2504
            string fName;
            unsafe
            {
                var hWnd = WinRT.Interop.WindowNative.GetWindowHandle(window);

                var hr = PInvoke.CoCreateInstance<IFileDialog>(
                    typeof(FileOpenDialog).GUID,
                    null,
                    CLSCTX.CLSCTX_INPROC_SERVER,
                    out var fsd);
                Marshal.ThrowExceptionForHR(hr);

                // Set filters (e.g. "*.yaml", "*.yml", etc...)
                var extensions = new List<COMDLG_FILTERSPEC>();
                foreach (var filter in filters)
                {
                    COMDLG_FILTERSPEC extension;
                    extension.pszName = (char*)Marshal.StringToHGlobalUni(filter.Name);
                    extension.pszSpec = (char*)Marshal.StringToHGlobalUni(filter.Type);
                    extensions.Add(extension);
                }

                fsd.SetFileTypes(extensions.ToArray());

                fsd.Show(new HWND(hWnd));
                fsd.GetResult(out var ppsi);

                PWSTR pFileName;
                ppsi.GetDisplayName(SIGDN.SIGDN_FILESYSPATH, &pFileName);
                fileName = new string(pFileName);
            }

            return await StorageFile.GetFileFromPathAsync(fileName);
        }
        catch (Exception e)
        {
            return null;
        }
    }

Repro recording

In this video, the third attempt shows the bug described in this issue where clicking the checkbox control becomes non-responsive.

FilePickerBug.mp4

Expected behavior

When dialog closes, application UI is unblocked.

Screenshots

Video attached above.

NuGet package version

WinUI 3 - Windows App SDK 1.3.1: 1.3.230502000

Windows version

Windows Insider Build (xxxxx)

Additional context

No response

[AmelBawa-msft]

Workaround: Hover outside the main window, un-focus/re-focus, resize window.

[shane-vorwerk]

I am experiencing the same issue in my application. I hope that this is fixed in the near future as it is blocking an important feature. Note: this is running with standard windows privileges and is not elevated.

[zhuxb711]

Workaround: Hover outside the main window, un-focus/re-focus, resize window.

Actually, drag the title bar and the UI response again. So same issue here.

[castorix]

I am experiencing the same issue in my application. I hope that this is fixed in the near future as it is blocking an important feature. Note: this is running with standard windows privileges and is not elevated.

I cannot reproduce this problem in the test I had done with P/Invoke from C++ headers
(WinUI3_IFileDialog), with Windows App SDK 1.1.0

[shane-vorwerk]

I cannot reproduce this problem in the test I had done with P/Invoke from C++ headers (WinUI3_IFileDialog), with Windows App SDK 1.1.0

I am using the latest 1.3 version of the SDK (also tested with 1.4 experimental). This issue happens often but not every time. However, it happens often enough to cause a noticeable problem with the feature I am implementing. I believe there are other conflicts in the SDK or UI thread that freeze the application UI.

After looking at your GitHub code, I realize we are using different File Open Dialogs. I am using:

 [DllImport("Comdlg32.dll", CharSet = CharSet.Auto)]
public static extern bool GetOpenFileName([In, Out] OpenFileName ofn);

So maybe your approach works around the UI freezing issue.

Further Edit:
I tested your CFileDialog as a replacement, and it seems to have reduced the UI freezing but I have still encountered it a few times during testing.

[wizcas]

I cannot reproduce this problem in the test I had done with P/Invoke from C++ headers (WinUI3_IFileDialog), with Windows App SDK 1.1.0

I use IFileOpenDialog from Shell32 (wrapped by Vanara.PInvoke) and is also experiencing the freezing issue. Even worse than @shane-vorwerk , I can reproduce EVERY SINGLE TIME.

My dialog constructing code can be found here

[brentesh]

I'm reproducing the same issue when printing to PDF (and selecting a folder) with a Telerik PdfViewer. Telerik has informed me that it is caused by this bug.

[codendone]

In theory this should be fixed in 1.3.3 (1.3.230724000) by this change:

Fixed an issue where the mouse would sometimes stop working when a dialog box was closed.

[AmelBawa-msft]

@codendone, thank you! I am closing this issue as from my tests I couldn't repro the bug in latest release of the SDK (1.3.230724000) in Dev Home and in the test app from this issue's description. Please re-open if this was not resolved for others.