-
Notifications
You must be signed in to change notification settings - Fork 515
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
In the scene:willConnectToSession:options:, accessing connectionOptions.UserActivities throws #16378
Labels
Milestone
Comments
I can reproduce this issue with the Microsoft.Maui.sln at https://github.com/dotnet/maui - build and run the Sample project targeting iOS. |
I was also able to repro this now with a small sample project: https://github.com/mattleibow/MauiMultiWindowSample Just download and run mac catalyst.
|
I can reproduce. It looks like it's a duplicate/variation of #13704. |
rolfbjarne
added
bug
If an issue is a bug or a pull request a bug fix
dotnet
An issue or pull request related to .NET (6)
labels
Oct 27, 2022
rolfbjarne
added a commit
to rolfbjarne/xamarin-macios
that referenced
this issue
Oct 27, 2022
…if the existing one is of the wrong type. Fixes xamarin#13704. Objective-C has an optimization where creating an empty dictionary would return the same instance every time (probably to a constant empty dictionary). This causes a problem with how we've bound generic dictionaries, because all empty dictionaries would have the same native handle, even if we'd bound them with different managed types. This surfaces in unfortunate ways when we try to look up a managed instance given a native handle, we find that we already have a managed instance, but the managed instance is of the wrong type. Example code: var a = new NSDictionary (); var b = new NSDictionary<NSString, NSString> (); var c = new NSDictionary<NSString, NSObject> (); Console.WriteLine ($"a: 0x{a.Handle:X}"); Console.WriteLine ($"b: 0x{b.Handle:X}"); Console.WriteLine ($"c: 0x{c.Handle:X}"); would produce something like: a: 0x0x7fff80821080 b: 0x0x7fff80821080 c: 0x0x7fff80821080 now for this code: Runtime.GetNSObject<NSDictionary<NSString, NSString>> (b.Handle) it would throw an exception like this: Unable to cast object of type 'Foundation.NSDictionary`2[[Foundation.NSString],[Foundation.NSObject]]' to type 'Foundation.NSDictionary`2[[Foundation.NSString],[Foundation.NSString]]' because we'll have the 'c' object (with type `NSDictionary<NSString, Object>`) in our dictionary of native handles -> managed instances, and that's not compatible with the desired return type from GetNSObject (`NSDictionary<NSString, NSString>`) This likely happens with all the non-mutable collection types we have a generic version of (NSArray, NSDictionary, NSOrderedSet, NSSet). Fixes xamarin#16378. Fixes xamarin#13704.
rolfbjarne
added a commit
that referenced
this issue
Oct 28, 2022
…if the existing one is of the wrong type. Fixes #13704. (#16491) Objective-C has an optimization where creating an empty dictionary would return the same instance every time (probably to a constant empty dictionary). This causes a problem with how we've bound generic dictionaries, because all empty dictionaries would have the same native handle, even if we'd bound them with different managed types. This surfaces in unfortunate ways when we try to look up a managed instance given a native handle, we find that we already have a managed instance, but the managed instance is of the wrong type. Example code: var a = new NSDictionary (); var b = new NSDictionary<NSString, NSString> (); var c = new NSDictionary<NSString, NSObject> (); Console.WriteLine ($"a: 0x{a.Handle:X}"); Console.WriteLine ($"b: 0x{b.Handle:X}"); Console.WriteLine ($"c: 0x{c.Handle:X}"); would produce something like: a: 0x0x7fff80821080 b: 0x0x7fff80821080 c: 0x0x7fff80821080 now for this code: Runtime.GetNSObject<NSDictionary<NSString, NSString>> (b.Handle) it would throw an exception like this: Unable to cast object of type 'Foundation.NSDictionary`2[[Foundation.NSString],[Foundation.NSObject]]' to type 'Foundation.NSDictionary`2[[Foundation.NSString],[Foundation.NSString]]' because we'll have the 'c' object (with type `NSDictionary<NSString, Object>`) in our dictionary of native handles -> managed instances, and that's not compatible with the desired return type from GetNSObject (`NSDictionary<NSString, NSString>`) This likely happens with all the non-mutable collection types we have a generic version of (NSArray, NSDictionary, NSOrderedSet, NSSet). Fixes #16378. Fixes #13704.
vs-mobiletools-engineering-service2
pushed a commit
to vs-mobiletools-engineering-service2/xamarin-macios
that referenced
this issue
Oct 28, 2022
…if the existing one is of the wrong type. Fixes xamarin#13704. Objective-C has an optimization where creating an empty dictionary would return the same instance every time (probably to a constant empty dictionary). This causes a problem with how we've bound generic dictionaries, because all empty dictionaries would have the same native handle, even if we'd bound them with different managed types. This surfaces in unfortunate ways when we try to look up a managed instance given a native handle, we find that we already have a managed instance, but the managed instance is of the wrong type. Example code: var a = new NSDictionary (); var b = new NSDictionary<NSString, NSString> (); var c = new NSDictionary<NSString, NSObject> (); Console.WriteLine ($"a: 0x{a.Handle:X}"); Console.WriteLine ($"b: 0x{b.Handle:X}"); Console.WriteLine ($"c: 0x{c.Handle:X}"); would produce something like: a: 0x0x7fff80821080 b: 0x0x7fff80821080 c: 0x0x7fff80821080 now for this code: Runtime.GetNSObject<NSDictionary<NSString, NSString>> (b.Handle) it would throw an exception like this: Unable to cast object of type 'Foundation.NSDictionary`2[[Foundation.NSString],[Foundation.NSObject]]' to type 'Foundation.NSDictionary`2[[Foundation.NSString],[Foundation.NSString]]' because we'll have the 'c' object (with type `NSDictionary<NSString, Object>`) in our dictionary of native handles -> managed instances, and that's not compatible with the desired return type from GetNSObject (`NSDictionary<NSString, NSString>`) This likely happens with all the non-mutable collection types we have a generic version of (NSArray, NSDictionary, NSOrderedSet, NSSet). Fixes xamarin#16378. Fixes xamarin#13704.
dalexsoto
pushed a commit
that referenced
this issue
Oct 28, 2022
…ew instance if the existing one is of the wrong type. Fixes #13704. (#16502) Objective-C has an optimization where creating an empty dictionary would return the same instance every time (probably to a constant empty dictionary). This causes a problem with how we've bound generic dictionaries, because all empty dictionaries would have the same native handle, even if we'd bound them with different managed types. This surfaces in unfortunate ways when we try to look up a managed instance given a native handle, we find that we already have a managed instance, but the managed instance is of the wrong type. Example code: var a = new NSDictionary (); var b = new NSDictionary<NSString, NSString> (); var c = new NSDictionary<NSString, NSObject> (); Console.WriteLine ($"a: 0x{a.Handle:X}"); Console.WriteLine ($"b: 0x{b.Handle:X}"); Console.WriteLine ($"c: 0x{c.Handle:X}"); would produce something like: a: 0x0x7fff80821080 b: 0x0x7fff80821080 c: 0x0x7fff80821080 now for this code: Runtime.GetNSObject<NSDictionary<NSString, NSString>> (b.Handle) it would throw an exception like this: Unable to cast object of type 'Foundation.NSDictionary`2[[Foundation.NSString],[Foundation.NSObject]]' to type 'Foundation.NSDictionary`2[[Foundation.NSString],[Foundation.NSString]]' because we'll have the 'c' object (with type `NSDictionary<NSString, Object>`) in our dictionary of native handles -> managed instances, and that's not compatible with the desired return type from GetNSObject (`NSDictionary<NSString, NSString>`) This likely happens with all the non-mutable collection types we have a generic version of (NSArray, NSDictionary, NSOrderedSet, NSSet). Fixes #16378. Fixes #13704. This PR is somewhat simpler to review by ignoring whitespace: https://github.com/xamarin/xamarin-macios/pull/16491/files?w=1 Backport of #16491 Co-authored-by: Rolf Bjarne Kvinge <[email protected]>
ghost
locked as resolved and limited conversation to collaborators
Nov 27, 2022
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Steps to Reproduce
Expected Behavior
No exception
Actual Behavior
Exception
Environment
Version information
Build Logs
Example Project (If Possible)
The text was updated successfully, but these errors were encountered: