Bug 59244 - Back button not appearing on UWP when await in OnStart
Summary: Back button not appearing on UWP when await in OnStart
Alias: None
Product: Forms
Classification: Xamarin
Component: Forms ()
Version: 2.3.4
Hardware: PC Windows
: --- normal
Target Milestone: ---
Assignee: Bugzilla
Depends on:
Reported: 2017-09-05 23:33 UTC by John Hardman
Modified: 2017-10-13 14:51 UTC (History)
3 users (show)

Is this bug a regression?: ---
Last known good build:

Solution that demonstrates the problem (988.96 KB, application/zip)
2017-09-05 23:35 UTC, John Hardman

Notice (2018-05-24): bugzilla.xamarin.com is now in read-only mode.

Please join us on Visual Studio Developer Community and in the Xamarin and Mono organizations on GitHub to continue tracking issues. Bugzilla will remain available for reference in read-only mode. We will continue to work on open Bugzilla bugs, copy them to the new locations as needed for follow-up, and add the new items under Related Links.

Our sincere thanks to everyone who has contributed on this bug tracker over the years. Thanks also for your understanding as we make these adjustments and improvements for the future.

Please create a new report on Developer Community or GitHub with your current version information, steps to reproduce, and relevant error messages or log files if you are hitting an issue that looks similar to this resolved bug and you do not yet see a matching new report.

Related Links:

Description John Hardman 2017-09-05 23:33:44 UTC
Using XF, on UWP (desktop), the back button sometimes does not appear when it is expected to appear.

It's not 100% repeatable, but what it seems to be is as follows:

The OnStart method of the PCL is marked as async
In the OnStart method of the PCL, call an awaited method (e.g. DisplayAlert)
It seems that the longer the await is outstanding, the more likely the back button is to not appear, so using DisplayAlert leave it on display for a few minutes, then hit a button to get rid of the alert.
Navigate to another page (in the attached app there is a button that does this)
The page navigated to should show a back button. It often doesn't. If it does show the back button, run it again and leave the DisplayAlert on screen for longer.

I have attached a solution that demonstrates the problem. Build the UWP project and run on desktop. Follow the above steps and the on-screen instructions.
Comment 1 John Hardman 2017-09-05 23:35:51 UTC
Created attachment 24584 [details]
Solution that demonstrates the problem

Please ignore the bug number in the title of the solution. This solution evolved from another repro sample.
Comment 2 John Hardman 2017-09-05 23:36:55 UTC
Apologies - that should have said, not
Comment 3 Paul DiPietro [MSFT] 2017-09-06 15:29:57 UTC
How often does this occur for you, would you say? After not having success with wait periods of a few minutes, I ran the sample and left it running on a few occasions for quite a long while (upwards of 20 minutes) while doing other things before returning to it and each time the back button appeared as expected. I imagine you're likely running on the current stable/non-insider release of Windows 10? I will try to get someone else to try to run the reproduction on their machine to see if their results are different, but I'm wondering if there's any more info which might be helpful for this.
Comment 4 John Hardman 2017-09-06 15:57:00 UTC
If left for 3 or 4 minutes, it happens most of the time.

I'm running Windows 10 Pro 64 bit, version 1703 (OS Build 15063.540)
Comment 5 John Hardman 2017-09-06 16:00:14 UTC
In my real app (as opposed to the repro sample), I use James Montemagno's permissions plugin to check that my app has been given permission to do various things. The permissions check can pop up a Yes/No prompt - if the user has wandered off for a few minutes and then clears that popup, the back button is likely to not appear on subsequent pages.

The repro sample uses a simple DisplayAlert to reproduce the missing back button.
Comment 6 Paul DiPietro [MSFT] 2017-09-07 13:31:33 UTC
A second person has tested the reproduction and is also unable to reproduce the behavior. We trust that you're experiencing this but we'll need to wait until someone else can validate running into it. In the meantime I'd also suggest testing the 2.4.0 prerelease to see if it makes any changes at all on your end, if only due to the number of fixes in the release. I'd like to leave this on needinfo for now until we can get further evaluation from others.
Comment 7 Paul DiPietro [MSFT] 2017-10-06 17:53:04 UTC
For for the time being I'm going to mark this as not reproducible as we haven't had any other reports for about a month (along with the aforementioned inability to reproduce the behavior by someone else), and will assume it isn't an issue on 2.4.0. If it still occurs as of 2.4.0 and we can get some more concrete steps than what was provided, this can of course be reopened.
Comment 8 John Hardman 2017-10-13 14:51:05 UTC
Still a problem on