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

[iOS] Fix NavigationPage memory leak when back button title is set #523

Merged
merged 4 commits into from Feb 9, 2017

Conversation

Projects
None yet
5 participants
@adrianknight89
Contributor

adrianknight89 commented Nov 12, 2016

Description of Change

SetBackButtonTitle on iOS creates a memory leak when the page on which it's called is popped from the navigation stack. This is because BackBarButtonItem has an event handler that holds a reference to the page. The simplest fix was to remove this handler. It looks like iOS is overriding the behavior so that the handler is never called.

I tried setting the Clicked event of UIBarButtonItem, using a UIButton as custom view and handling its TouchUpInside, and removing the tap gesture from pageRenderer.ViewController.View. None of those allowed me to invoke await PopViewAsync(page), which makes me believe BackBarButtonItem (or something else) is overriding everything. Removing the handler lets us use the default back button logic.

P.S. I can't quite understand what DidMoveToParentViewController is doing. The comments were vague to me, and this method is triggering a call to Task<bool> OnPopViewAsync where an exception (wrapped in the Task) is thrown all the time because TopViewController is not the parent of the page being removed. I think there was a bug report related to this exception. @rmarinho

Bugs Fixed

PR Checklist

  • Has tests (if omitted, state reason in description)
  • Rebased on top of master at time of PR
  • Changes adhere to coding standard
  • Consolidate commits as makes sense

@rmarinho rmarinho self-assigned this Nov 16, 2016

@rmarinho

This comment has been minimized.

Show comment
Hide comment
@rmarinho

rmarinho Nov 18, 2016

Member

Hi @adrianknight89 so i was looking at this and specially code of DidMoveToParentViewController was missing stuff, seems that maybe the rebase got wrong, and we merged a incomplete fix. pr (#291)

At this time i reverted that code so we can ship stable that doesn't throw that exception, also it was making impossible to dispose some renderers. But i will get back to try to fix that bug again 39908.

Just to explain you my fix there, the problem is when a page is popped via click on the back button very fast the way we update the stack on the XF side gets mixed up. So i used other aproach: DidMoveToParentViewController is called with parent null when a ViewController is being removed, and in there we check if we should update the Forms side ( normally always that pop is done via the UI and not using XF api) .. But the current code was missing stuff. I need to get back to it.

Please rebase and check if this leak that you are trying to fix still happens.

Thanks.

Member

rmarinho commented Nov 18, 2016

Hi @adrianknight89 so i was looking at this and specially code of DidMoveToParentViewController was missing stuff, seems that maybe the rebase got wrong, and we merged a incomplete fix. pr (#291)

At this time i reverted that code so we can ship stable that doesn't throw that exception, also it was making impossible to dispose some renderers. But i will get back to try to fix that bug again 39908.

Just to explain you my fix there, the problem is when a page is popped via click on the back button very fast the way we update the stack on the XF side gets mixed up. So i used other aproach: DidMoveToParentViewController is called with parent null when a ViewController is being removed, and in there we check if we should update the Forms side ( normally always that pop is done via the UI and not using XF api) .. But the current code was missing stuff. I need to get back to it.

Please rebase and check if this leak that you are trying to fix still happens.

Thanks.

@adrianknight89

This comment has been minimized.

Show comment
Hide comment
@adrianknight89

adrianknight89 Nov 19, 2016

Contributor

Looks like reverting your changes makes things better. However, I'm still unable to call await PopViewAsync(page);. It seems that iOS is ignoring this.

Contributor

adrianknight89 commented Nov 19, 2016

Looks like reverting your changes makes things better. However, I'm still unable to call await PopViewAsync(page);. It seems that iOS is ignoring this.

@rmarinho

This comment has been minimized.

Show comment
Hide comment
@rmarinho

rmarinho Dec 17, 2016

Member

needs rebase

Member

rmarinho commented Dec 17, 2016

needs rebase

@adrianknight89

This comment has been minimized.

Show comment
Hide comment
@adrianknight89

adrianknight89 Dec 17, 2016

Contributor

Done.

Contributor

adrianknight89 commented Dec 17, 2016

Done.

@jerone

This comment has been minimized.

Show comment
Hide comment
@jerone

jerone Jan 21, 2017

@adrianknight89 commented on 19 Nov 2016, 17:44 CET:

Looks like reverting your changes makes things better. However, I'm still unable to call await PopViewAsync(page);. It seems that iOS is ignoring this.

I can conclude the same thing, when I assign my own back-button. It's completely ignoring the event-handler and calling page pop on it's own.

jerone commented Jan 21, 2017

@adrianknight89 commented on 19 Nov 2016, 17:44 CET:

Looks like reverting your changes makes things better. However, I'm still unable to call await PopViewAsync(page);. It seems that iOS is ignoring this.

I can conclude the same thing, when I assign my own back-button. It's completely ignoring the event-handler and calling page pop on it's own.

@rmarinho rmarinho merged commit 56e3629 into xamarin:master Feb 9, 2017

6 checks passed

Android-UITests-C8 Finished TeamCity Build Xamarin.Forms :: Debug :: Cycle 8 :: UI Tests :: OSX Test Cloud Package - Run Android 6.0.1 : Tests passed: 352, i…
Details
OSX-Debug-C8 Finished TeamCity Build Xamarin.Forms :: Debug :: Cycle 8 :: OSX Debug : Running
Details
Windows-Debug-C8 Finished TeamCity Build Xamarin.Forms :: Debug :: Cycle 8 :: Windows Debug : Tests passed: 3738, ignored: 10
Details
iOS10-UITests-C8 Finished TeamCity Build Xamarin.Forms :: Debug :: Cycle 8 :: UI Tests :: OSX Test Cloud Package - Run iOS Unified iOS10 : Tests passed: 34…
Details
iOS8-UITests-C8 Finished TeamCity Build Xamarin.Forms :: Debug :: Cycle 8 :: UI Tests :: OSX Test Cloud Package - Run iOS Unified IOS8 : Tests passed: 349…
Details
iOS9-UITests-C8 Finished TeamCity Build Xamarin.Forms :: Debug :: Cycle 8 :: UI Tests :: OSX Test Cloud Package - Run iOS Unified iOS9 : Tests passed: 351…
Details

@samhouts samhouts added D-15.4 and removed cla-already-signed labels Oct 10, 2017

@samhouts samhouts modified the milestone: 3.1.0 Jun 1, 2018

@samhouts samhouts added this to Done in vNext+1 (master) Jun 26, 2018

@samhouts samhouts removed this from Done in vNext+1 (master) Jun 26, 2018

@samhouts samhouts added this to the 2.3.5 milestone Jun 27, 2018

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment