Bug 59163 - Crash on a single Forms Previewer page shouldn't stop future pages displaying
Summary: Crash on a single Forms Previewer page shouldn't stop future pages displaying
Alias: None
Product: Visual Studio Extensions
Classification: Xamarin
Component: Xamarin.Forms Previewer (show other bugs)
Version: 4.7.0 (15.4)
Hardware: PC Windows
: --- normal
Target Milestone: 15.6
Assignee: Bugzilla
Depends on:
Reported: 2017-08-31 22:44 UTC by Bret Johnson [MSFT]
Modified: 2017-10-26 22:38 UTC (History)
3 users (show)

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

Screenshot (13.39 KB, text/plain)
2017-08-31 22:44 UTC, Bret Johnson [MSFT]

Description Bret Johnson [MSFT] 2017-08-31 22:44:34 UTC
Created attachment 24510 [details]

Use the Forms Previewer in a way that results in a native crash, in the Java process when previewing.

You might think such crashes are rare, but here are two scenarios that cause them that I found:

And likely there are others.

Anyway, once the layoutlib java process crashes, we relaunch it with custom controls disabled.

After that, when the user tries to preview other Forms pages they just showing a solid grey rectangle with the text XFPageRenderView. See attached screenshot. Every future previewed Forms page will show that, even in different solutions, until the IDE is restarted.

Preferred behavior:

For the native Android designer, disabling custom controls makes sense, so if a custom control causes a crash you can at least see non-custom controls.

But for the Forms previewer everything is a custom control so a mode where they are disabled provides no value to the user.  For the Forms previewer it would be better to never go into this "custom controls disabled" mode, 
instead just relaunching the the previewer on crash in the normal mode.  That way, subsequent pages that crash will still crash, showing an error which is fine, even desirable, but all other pages will display OK.
Comment 1 Alan McGovern 2017-09-04 13:55:25 UTC
I would love to include this in d15-4 but unfortunately even if a fix were available today we would not be allowed to include it.

However we should attempt to improve this for d15-5.
Comment 2 David Ortinau [MSFT] 2017-10-05 18:41:11 UTC
Alan, I'm moving this to 15-6 unless you tell me this is fixed and ready to go today.
Comment 3 Alan McGovern 2017-10-05 22:04:09 UTC
We don't have  fix but we should still endeavour to include one!
Comment 5 Bret Johnson [MSFT] 2017-10-26 22:38:35 UTC
None of the fix options possible in 15.5 look very attractive here. Pushing to 15.6.

Note You need to log in before you can comment on or make changes to this bug.