Fix init order of SetupWithClassicDesktopLifetime

[MrJul]

What does the pull request do?

This PR fixes an initialization order bug when AppBuilder.SetupWithClassicDesktopLifetime() is called instead of StartWithClassicDesktopLifetime().

What is the current behavior?

When SetupWithClassicDesktopLifetime is used, internal events are registered before the AppBuilder initializers run: at that point, many subsystems aren't available yet, causing issues such as ShutdownRequested not being hooked up. Additionally, Startup is called way earlier, or might be called twice if Start() is called manually on the created lifetime.

A related problem arises when calling AppBuilder.SetupWithLifetime() manually without Start: the internal event handlers aren't even initialized.

On macOS, this causes the ShutdownRequested event not to be called when quitting the app from the dock, then triggering a double close of the main window (and hitting a debug assertion).

What is the updated/expected behavior with this PR?

StartWithClassicDesktopLifetime, SetupWithClassicDesktopLifetime and SetupWithLifetime initialize the subsystems and event handlers in the same exact order.

Quitting a macOS application raises the ShutdownRequested event correctly and respects its cancellation.

Unit tests have been added.

How was the solution implemented (if it's not obvious)?

An internal ISetupApplicationLifetime is added and implemented by ClassicDesktopStyleApplicationLifetime. The AppBuilder is responsible for calling it to initialize the lifetime in the correct order properly.

Fixed issues

• Fixes 'Quit' option in dock menu on macOS can't be canceled when SetupWithClassicDesktopLifetime() is used #20683

[avaloniaui-bot]

You can test this PR using the following package version. 12.2.999-cibuild0068218-alpha. (feed url: https://nuget-feed-all.avaloniaui.net/v3/index.json) [PRBUILDID]

[MrJul]

I disagree. The whole point of this PR is to make it consistent: Startup is always raised from the same place, here Setup (unfortunately). There might be no Start() call at all!

In other words, Setup(new ClassicDesktopStyleApplicationLifetime()) and SetupWithClassicDesktopLifetime should have the same behavior with regard to when/if Startup is raised. That's why this PR adds it directly to the base builder instead of special-casing just one path.

In v13, we should remove this hack and take the breaking change that Startup is only called when Start is, solving both issues and respecting the arguments.

[MrJul]

Having thought about it more, the fact that Setup was raising Startup is also part of the bug. The whole initialization order was incorrect. I've changed my stance: Startup is now raised only when Start is called, not on Setup.

This makes the whole thing sane, without hacks.

The following numbers helped this decision:

• SetupWithClassicDesktopLifetime: 78 hits
• StartWithClassicDesktopLifetime : 19800 hits

Users of Setup are few, and such users know when their app starts, so the Startup event is irrelevant there, especially since it was called immediately from Setup, which is user-controlled.

[avaloniaui-bot]

You can test this PR using the following package version. 12.2.999-cibuild0069303-alpha. (feed url: https://nuget-feed-all.avaloniaui.net/v3/index.json) [PRBUILDID]

The args are now respected.