Notice (2018-05-24): bugzilla.xamarin.com is now in
Please join us on
Visual Studio Developer Community and in the
Mono organizations on
GitHub to continue tracking issues. Bugzilla will remain
available for reference in read-only mode. We will continue to work
on open Bugzilla bugs, copy them to the new locations
as needed for follow-up, and add the new items under Related
Our sincere thanks to everyone who has contributed on this bug
tracker over the years. Thanks also for your understanding as we
make these adjustments and improvements for the future.
Please create a new report on
Developer Community or GitHub with
your current version information, steps to reproduce, and relevant error
messages or log files if you are hitting an issue that looks similar to
this resolved bug and you do not yet see a matching new report.
I am seeing a System.ArgumentNullException on the OnElementChanged/OnCollectionChanged of the MapRenderer on iOS. The exception says "System.ArgumentNullException: Value cannot be null.
Parameter name: annotations".
It's hard to reproduce in a repo project since I think it's a timing issue; however, I have attached a stack trace. I've looked at the renderer code on iOS, and I see the RemoveAnnotations is called in the OnElementChanged.OnCollectionChanged.Reset trigger (Line 278 is the trigger, and the code that throws the exception is Line 375).
For whatever reason, my guess is the MKMapView.Annotations is now returning NULL instead of an empty array. I don't think there's any workaround for this issue in a custom renderer, and it's definitely a show stopper for anyone using maps.
The way to reproduce it is to get the Annotations to return null, then it will throw the exception.
Created attachment 25279 [details]
Attached a stack trace.
Ok good news. I think it has something to do with the MKMapView being disposed, and then it's being referenced in the collection. I did manual dispose of the MKMapView and I received the exact exception (ArgumentNull with annotations).
I'm not sure why the MKMapView is being disposed though.
I downgraded to Forms 2.3, and the issue is no longer there. It seems to be an issue with Forms 2.4. From what I can tell, the MKMapView (Control) is disposed when OnElementChanged.OldElement is not null. Then, the OnElementChanged.NewElement is triggered when map is created on a new page; however, the MKMapView is pooled and for some reason has been disposed.
I can't seem to trigger a Dispose in a demo app, but I can see it's an issue if the MapPool's MKMapView instance is disposed and then re-used.
I did attach a sample project which calls Dispose, and then you can see the ArgumentException the next time OnElementChanged is fired. I deleted all of the packages.
Tested on iOS 11 simulator.
Created attachment 25281 [details]
Ok better news! I got it to reproduce consistently. The issue happens when using a custom renderer Map in a ListView header (which is what I'm doing in a project).
I've attached a project that reproduces the issue named "ListView Bug". I looked at the source code in Forms, and the following gist is suspect.
Created attachment 25285 [details]
Steps to Reproduce
In order to reproduce in the project, tap on an item on the first page. Navigate back to the first page. Then tap on an item again which navigates to the next page.
Thanks for the detailed report! I'm also able to reproduce this issue, so marking it as a confirmed regression.
Please do not dispose the map view in your default renderer. We pool the map view and disposing it corrupts the pool.
The attached project named ListView Bug does not dispose of the Renderer. It uses the Map in a ListView header which for some reason causes the Map to get disposed in the Pool.
When that happens, the ArgumentException gets raised. I don't think a null check will work in this scenario unless the map isn't being disposed anymore.
I just verified this fix does not work in the current version of Xamarin Forms. Can we please update this fix to not resolved? The map gets disposed and is blank in the header. Please see the "ListView Bug" attached.
Did some more research... It turns out that the following commit may have resolved the issue, but it was issued 9 days ago (a lot later than this fix).
Specifically the DisposeSubviews method fix.
Adding the null check does not resolve the issue at all (only hides it). Not sure what the UI tests look like, but I think they may need to get reworked as well. Please let me know your findings. Thanks.
Nix that last comment. Turns out that latest fix actually causes the Dispose method to never get called on the MapRenderer. So, now with the latest fix, the MKMapView is never actually cached.
Should be fixed on 2.5.0-sr4