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.
We've encountered this as well. You can reproduce it with the DataGrid github project.
Set demo.Windows as the startup project.
These two fail: "Test 4" and "Test Xaml". All others work fine.
To prevent the error, reduce the number of views on the screen. If you edit the portable App.cs to remove one of the columns from the failing test, you won't get the error.
Similarly, if you add more columns and rows to the succeeding test, they will fail. For the Million test case, 5 columns will fail, but 4 columns will succeed.
Thanks for your comment.
We are facing this error whenever we reuse the view upon scrolling regardless of number of columns in view. This is not because of the number of views in view, this is because of calling InvalidateMeasure when changing the BindingContext of a view in Xamarin as it is not a great idea to invalidate from the root element for every changes in child elements. Hence this needs to be skipped by some means to use Xamarin for developing large Application.
If not then it would be a tough work to develop a big application that involves more number of child elements with these kind of layout passes. I hope Xamarin would consider this as a serious issue and get this fixed soon.
Currently am helpless with no clues to fix this issue. This is making the users of my application to stick to the 220.127.116.1171 version of nugets to avoid this issue, which is not an acceptable one for long time. I hope Xamarin understands the seriousness of this issue and get this fixed soon with the maximum priority they could. Thanks a lot in advance.
Any update on the reported issue?
We have a release for our product by next week which highly depends on the fix for the reported issue. So can you guys please get back on this ASAP? We need fix for this issue as quick as possible. Hope Xamarin will consider the seriousness about this. Please let us know the status of this bug and the exact time of when the fix will be available.
Seems a lot of people facing the same problem. I could see this from the bug thread here below.
But Xamarin does not seem to update anything on this about when this will be fixed. At present am totally stuck and frustrated as this avoids in updating to the latest nugets. Whereas my customers prefer to update to the latest forms version.
Am using the Xamarin.Forms.ImageSource.FromResource("") method in my source to process the images. As a result, updating only the samples in the customer side leads to a "Method missing exception" in my source as there seems to be some changes in Xamarin.Forms.ImageSource class which is getting resolved only if I update my source to latest. This is making me neither to update, nor to downgrade leaving me clueless.
I would rather prefer to escalate this if there were an option for it. Hope Xamarin understands the seriousness of this issue and fixes it soon.
As stated before, regarding the "Method Missing exception" when using ImageSource.FromResource("") method, I was able to reproduce this even in a simple sample and have reported it as a separate bug in the below thread.
Hope it gets fixed soon.
Just as an update, we are aware of this issue. Essentially we are hitting up against some kind of internal limit in Windows. We are not actually hitting an infinite loop.
Unfortunately this limit is not publicly specified so its a bit loose trying to figure out how to resolve it.
Just an idea,
1. On Checking about this issue, I noticed that Xamarin has made an Invalidate Call on TextProperty change of Label(something like "Xamarin.Forms.InvalidationTrigger trigger = RendererReady", I see in call stack) when its BindingContext is changed. This Invalidate calls makes call to the parent of label and its parent recursively, may be to refresh the text change in view.
2. But in our case, there will be 40 to 50 labels in view and for each label the invalidate measure makes a root layout pass resulting in cyclic layout calls.
3. So my idea would be to provide an option to skip this invalidation for a view, when BindingContext is changed. I guess we already have two such overrides "ShouldInvalidateOnChildAdded and ShouldInvalidateOnChildRemoved". Like that it will be fine if another override "ShouldInvalidateOnBindingContextChanged" is introduced to skip invalidation when BindingContext is changed for a view. We can have the default value for the override as true. So that for those like us who does not needs this invalidation can skip it using that override.
Thank you for taking the time to submit this report. After reviewing the description of this bug, we believe it no longer affects the current version of Xamarin.Forms. If you are still experiencing the issue after updating your packages, please reopen this report with an attached reproduction.
For your convenience, we have created some reproduction best practices viewable here: https://gist.github.com/jassmith/92405c300e54a01dcc6d
Xamarin Forms Team