-
Notifications
You must be signed in to change notification settings - Fork 477
[Bug] Popup causes app to crash after changing app theme #1947
Comments
Anyone? |
@mfeingol a sample project would be great here... On XF the Views are aggressively disposed of, so (just a shoot in the dark) if the popup is dismissed it will be disposed already, and if anything else tries to access it will cause this exception |
Unfortunately I can't reproduce this in the debugger. I've only seen it in crash reports when I submit my app to the store. Based on the stack trace, a first possible approach to a fix might be to check for |
A gentle ping on this: would it be possible to release a new version with that check implemented? |
What you could do, in meanwhile, is to not reuse the same popup, always create a new instance of it. |
I am. If you look at the stack trace above, the problem isn't popup instance reuse, but theme changes resulting in |
Can you provide a sample that reproduces the issue? That's new |
I cannot. Like I said, the only time I've seen this is in stack traces on AppCenter crash reports, which arrive after I submit an app to the Google Play Store. My app opens a popup on startup, so my guess is the popup is closed and then Google test very quickly goes to the settings page and changes the first setting, which happens to be an app theme radio button. |
you can't reproduce it even on a release build? Or if you copy all the |
I've tried, but I haven't been able to reproduce it. My guess is the GC runs fast enough that the Popup is gone. The theme changed event in the stack trace is probably driven by a weak reference, right? |
@pictos: I'm still seeing this when publishing to the Play Store. Any chance you could try applying the potential solution I mentioned above? I don't think it would hurt anything. Thanks! |
Would you be able to try and apply your suggestion locally and see if it solves the issue, if so then we could include it in this repository. I am not keen on on trying some changes that we can't verify whether they fix the issue or not. |
I'm not able to reproduce the issue locally, so I wouldn't be able to verify a solution that way. Are you suggesting I compile a custom version of the toolkit and submit to the store? |
Yes exactly that. If you fork the repository, make your changes and compile it. You can then just reference that dll rather than the NuGet package and ship the app. If the change works then you are in a perfect position to open a PR with the changes on your fork. Alternatively you might be able to just include the Popup code in your codebase if that is your preferred option. I don't know if we are using any internals from Xamarin.Forms for the Popup though |
@bijington: I managed to extract Popup out of XCT and build a store release with this change applied: protected virtual void OnElementPropertyChanged(object sender, PropertyChangedEventArgs args)
{
+ if (isDisposed) return; After shipping the new release to the store, the unhandled ObjectDisposedException was no longer reported in the Popup renderer. So I think this change is effective at solving the problem. |
@mfeingol that is great to hear! Out of interest how long was the application running for with this new release? Basically how confident are you that the issue is resolved given it was difficult to reproduce in the first place? |
Repro was pretty regular with a Play Store submission, so I'm confident. Outside of that it's been impossible to repro. |
OK great! Well let's get this fix in and merged ready for the next release :). Are you comfortable opening a PR for it? Or would you prefer me to do it? |
…e taking action. Fixes xamarin#1947
Thanks. I submitted #1968 |
Description
I'm seeing this in crash reporting, so I don't know 100% what's going on. What I believe is happening is that a Popup has been opened and then closed, and then the app's theme changed from dark to light or vice-versa. The Popup receives that event, presumably because it has a weak reference registration dangling somewhere. When it attempts to process it, the renderer has already been disposed, so the result is an unhandled ObjectDisposedException.
I imagine a repro should be possible, but it wouldn't be 100% since there is presumably a race between the user and the GC. Presumably this can be solved via code inspection.
Stack Trace
Link to Reproduction Sample
N/A
Steps to Reproduce
See above.
Expected Behavior
Popup should handle this case and not throw an ODE.
Actual Behavior
It throws.
Basic Information
Workaround
None.
The text was updated successfully, but these errors were encountered: