Bug: Activating the app from its URI/CLI sometimes causes a crash

[Lamparter]

Description

When activating the app via an invalid protocol, for example files-dev:// or files-dev:test, the app does one of two things:

• if the app is already open, it crashes completely
• if the app is not open, it will open to the splash screen and hang indefinitely

Steps To Reproduce

1. Opened the Run dialogue box via Win+R
2. Entered an (invalid) app protocol URI, e.g. files-dev:test
3. Observed the behaviour as described in the 'Description' section of the issue

Files Version

0b8e0af

Windows Version

10.0.26200.8875

User ID

No response

Log File

debug.log

[Lamparter]

--------- UNHANDLED EXCEPTION ---------
>>>> HRESULT: -2146233080
--- MESSAGE ---
Index was outside the bounds of the array.
--- STACKTRACE ---
   at Files.App.MainWindow.InitializeApplicationAsync(Object activatedEventArgs)
   at CommunityToolkit.WinUI.DispatcherQueueExtensions.<>c__DisplayClass3_0.<<EnqueueAsync>b__1>d.MoveNext()
--- End of stack trace from previous location ---
   at Files.App.Extensions.DispatcherQueueExtensions.<>c__DisplayClass0_0.<<EnqueueOrInvokeAsync>b__0>d.MoveNext()
--- End of stack trace from previous location ---
   at Files.Shared.Extensions.SafetyExtensions.IgnoreExceptions(Func`1 action, ILogger logger, Type exceptionToIgnore)
   at Files.App.App.OnActivatedAsync(AppActivationArguments activatedEventArgs)
   at Files.App.Program.OnActivated(Object sender, AppActivationArguments args)
   at System.Threading.Tasks.Task.<>c.<ThrowAsync>b__124_1(Object state)
   at System.Threading.ThreadPoolWorkQueue.Dispatch()
   at System.Threading.PortableThreadPool.WorkerThread.WorkerThreadStart()
   at System.Threading.Thread.StartCallback()
--- SOURCE ---
System.Private.CoreLib
---------------------------------------

The program '[18484] Files.exe' has exited with code 0 (0x0).

[Lamparter]

The root cause is this line: https://github.com/files-community/Files/blob/main/src/Files.App/MainWindow.xaml.cs#L111

var unescapedValue = Uri.UnescapeDataString(parsedArgs[1].Split('&')[0]);

It assumes that the parsed arguments are not null/empty.

[yair100]

Claude was able to fix this by adding the following to MainWindow.xaml.cs after line 110.

if (parsedArgs.Length < 2)
{
	rootFrame.Navigate(typeof(MainPage), null, new SuppressNavigationTransitionInfo());
	break;
}

[Lamparter]

That's another way to do it, but the way I've implemented it in #18746 is more comprehensive (also, the fix that Claude suggested only fixes one part of the issue)

[yair100]

The changes in #18746 touch on some sensitive code, I would prefer we make as few changes as possible. Which issue remains after the suggested solution?