New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
fix macos crash at startup by not parsing all app arguments into uris. #14494
Conversation
@@ -13,12 +13,21 @@ internal class AvaloniaNativeApplicationPlatform : NativeCallbackBase, IAvnAppli | |||
void IAvnApplicationEvents.FilesOpened(IAvnStringArray urls) | |||
{ |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This method is never really executed anymore?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
still executed to maintain legacy behaviour, but it wont call the new uri api codepath from here.
You can test this PR using the following package version. |
You can test this PR using the following package version. |
We need this fix for macOS: AvaloniaUI/Avalonia#14494 because when reopening an already-open app from finder, it calls openURLs which crashes in 11.0.7 but Linux/X11 requires 11.0.7 or unreleased version for working menus so do just use the proper CI build instead of waiting for Avalonia to make a new release
This was caused due to the "FilesOpened" callback being unexpectedly raised for all command line arguments.
The recent PR #14106 implemented a Uri protocol raised event, where the data was parsed into a uri.
Its not possible to do this for all arguments.
This PR does the following:
Separate the macOS backend callbacks
(void)application:(NSApplication *)sender openFiles
and(void)application:(NSApplication *)application openURLs
into 2 separate callbacks in our backend (previously they were the same)Continue raising the legacy
RaiseUrlsOpened
codepath from the FilesOpened (as has worked for many years), to not break previous behaviour.Only raise the new uri handling code from the
openURLS
macOS callback, and use Uri.TryCreate ().This fixes the bug and ensures the old behaviour.
Fixes #14411