[Bug][iOS] Email.ComposeAsync with modal

[Maxima078]

Description

When using Email.ComposeAsync on iOS it sometimes hangs due to an access to a view that has been destroyed. A warning is displayed in output :
"Warning: Attempt to present <MFMailComposeViewController: 0x13eb0c000> on <Rg_Plugins_Popup_IOS_Renderers_PopupPageRenderer: 0x13f0f2980> whose view is not in the window hierarchy! ".

It's really easy to workaround, just close your modal after Email.ComposeAsync but this sounds weird to me to use the top level view component (which can disappear) in order to ask iOS to compose email. At least we could expect an exception to be thrown, what do you think?

Steps to Reproduce

1. Use a button within a modal (such as a popup from Rg.Plugins.Popup) bound to a command calling Email.ComposeAsync
2. When this click is handled close your modal (from xaml.cs for instance)

Expected Behavior

Email.ComposeAsync returns or throws an error

Actual Behavior

Email.ComposeAsync sometimes never returns and no exception is thrown. A warning is displayed saying the renderer is not in the window hierarchy anymore.

Basic Information

• Version with issue: 1.3.1

[jamesmontemagno]

Hmmm yeah, we could throw an exception here so developers don't close the window that they are presenting from. Closing the model after makes sense the most and just turning off animations. I will try to reproduce, but if you have a small repo that would be great for the team.

[Redth]

I noticed Rg Popups in use here too. I seem to recall they do something potentially with the window hierarchy as well. A repro sample would be useful as James mentioned.

[lrolleman]

I have also noticed this bug with the Popup plugin and both Email and Share in XE

I don't have any code I can share atm, however a simple workaround I found is to just use Task.Delay after dismissing the popup, with a 1 second or so delay (could probably get away with less, but I went with 1 second) to give the popup a chance to get out of the way.

[jamesmontemagno]

Yeah, I mean what is happening is that you are invoking the call and it requires the current active UIViewController to display it. So, it pops up, but then you dismiss it right away, which means when we try to dismiss it or present it, it is gone. Will investigate and try a repro. I think we may be able to replicate using a ActionSheet maybe....

[LittleCornerDev]

Not sure whether this is the same issue. If it isn't, please let me know, and I can open a separate issue.

The app I'm working on has a form with a list of user-entered emails and phone numbers that it loops through, aggregates, then calls Email.ComposeAsync() and/or Sms.ComposeAsync() for [after click of a "Save" ToolbarItem].

I don't close the form until both are called. Whichever one is called second is the one that fails and gets the warning:

Warning: Attempt to present <MFMailComposeViewController: 0x120f03000> on <MFMessageComposeViewController: 0x127594e00> whose view is not in the window hierarchy!

Warning: Attempt to present <MFMessageComposeViewController: 0x10cd6b800> on <MFMailComposeViewController: 0x12d899c00> whose view is not in the window hierarchy!

This issue happens regardless of whether the form is on top of a navigation stack (when using a data add form on tab click) or was pushed onto the navigation stack (when using a data edit form after being on the data view page first).

It does seem to be only for iOS. Android prompts to select both an email app and an sms app. iOS prompts to select whichever one the code called first, then stops with no exceptions thrown.

[vchelaru]

As mentioned by @LittleCornerDev I also noticed the same problem on iOS if I dismiss the view which called Sms.ComposeAsync.