UWP: After closing secondary window main app won't return to foreground after backgrounding

Matt B 96 Reputation points
2021-01-19T01:13:52.533+00:00

It appears that with certain controls as children in a secondary window, once the window is closed and the main app is backgrounded (minimized), the main app will have long and variable delays returning to the foreground after restoring, usually on the order of minutes or even more. This is very easy to reproduce with a SplitView, though I believe other (but not all) controls exhibit this same problem. Currently targeting Platform Version 2004.

Here's a simple class to launch a window, following the basic tutorial for using ApplicationView:

internal class TestWindow
    {
        private ApplicationView View;

        private Window window;

        public TestWindow(ApplicationView view)
        {
            View = view;
            View.Consolidated += OnConsolidated;
        }

        private void OnConsolidated(ApplicationView sender, ApplicationViewConsolidatedEventArgs args)
        {
            View.Consolidated -= OnConsolidated;
            window.Close();
        }

        public static async Task<bool> OpenWindowAsync()
        {
            CoreApplicationView newView = CoreApplication.CreateNewView();

            int newViewId = 0;

            await newView.Dispatcher.RunAsync(CoreDispatcherPriority.Normal, () =>
            {
                var appView = ApplicationView.GetForCurrentView();
                var window = new TestWindow(appView);
                window.window = Window.Current;
                newViewId = appView.Id;
                Window.Current.Content = new WindowContent();

                // You have to activate the window in order to show it later.
                Window.Current.Activate();
            });

            var ret = await ApplicationViewSwitcher.TryShowAsStandaloneAsync(newViewId);
            return ret;
        }
    }

Here is WindowContent.xaml:

<Page
    x:Class="Window_Test.WindowContent"
    xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
    xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
    xmlns:local="using:Window_Test"
    xmlns:d="http://schemas.microsoft.com/expression/blend/2008"
    xmlns:mc="http://schemas.openxmlformats.org/markup-compatibility/2006"
    mc:Ignorable="d"
    Background="{ThemeResource ApplicationPageBackgroundThemeBrush}">

    <SplitView/>
</Page>

Steps to reproduce:

  1. Open secondary window
  2. Close secondary window
  3. Minimize main window
  4. Restore main window

At this point the main window will not respond to input for some time. It usually will return to normal operation eventually, though this can take many minutes. I can see the EnteredBackground event being triggered (via logs), but the LeavingBackground event does not trigger until just before the main window becomes responsive again.

Universal Windows Platform (UWP)
{count} votes

Accepted answer
  1. Matt B 96 Reputation points
    2021-03-02T20:17:47.763+00:00

    I found this Github issue that describes the exact same problem: https://github.com/microsoft/microsoft-ui-xaml/issues/802

    It also gives a workaround solution that was not obvious to me and would explain why Roy was unable to reproduce this without a sample app. The issue seems to be caused by the EnteredBackground and LeavingBackground App lifecycle events. My sample used these events for logging purposes. Removing those event handlers seems to resolve the issue. This was especially insidious because it doesn't happen for all controls. I was able to trigger it with a SplitView in the secondary window but not with a handful of other controls I tested. The poster on Github used a ComboBox.

    So the best solution at the moment is to remove the EnteredBackground and LeavingBackground handlers.

    0 comments No comments

4 additional answers

Sort by: Most helpful
  1. Roy Li - MSFT 32,091 Reputation points Microsoft Vendor
    2021-01-20T05:56:29.733+00:00

    Hello,

    Welcome to Microsoft Q&A!

    I could reproduce this issue here. But the result is a little different, when restoring the main view, the app will never respond even waiting for a long time. After testing, the issue is caused by this line of code window.Close();. I'm not sure why I did not reproduce your issue at the first time but your sample did help me to locate the issue.

    You could try the following code:

      private void OnConsolidated(ApplicationView sender, ApplicationViewConsolidatedEventArgs args)  
            {  
                View.Consolidated -= OnConsolidated;  
                // window.Close();  
                window = null;  
            }  
    

    Thank you.


    If the response is helpful, please click "Accept Answer" and upvote it.
    Note: Please follow the steps in our documentation to enable e-mail notifications if you want to receive the related email notification for this thread.


  2. Heiko 1,211 Reputation points
    2021-02-06T16:32:58.52+00:00

    Should the Close() method be called in the thread of the the secondary window?

    Like this:

    private async void PrintPage_Consolidated(ApplicationView sender, ApplicationViewConsolidatedEventArgs args)
    {
        if (PrintPage != null)
        {
            await CoreViewPrint.Dispatcher.RunAsync(CoreDispatcherPriority.Normal, () =>
                {
                    CoreWindow.GetForCurrentThread().Close();
                    ApplicationView.GetForCurrentView().Consolidated -= PrintPage_Consolidated;
                });
    
            PrintPage = null;
            CoreViewPrint = null;
        }
    }
    

  3. Xiaoyan Hao 1 Reputation point
    2021-07-28T08:47:12.007+00:00

    any update here?
    same issue for me.

    0 comments No comments