Bug 865 - iPad crashed when phone call attempt is made
Summary: iPad crashed when phone call attempt is made
Alias: None
Product: iOS
Classification: Xamarin
Component: XI runtime ()
Version: 4.x
Hardware: PC Mac OS
: --- normal
Target Milestone: Untriaged
Assignee: Sebastien Pouliot
Depends on:
Reported: 2011-09-16 15:33 UTC by Ian
Modified: 2011-10-06 15:40 UTC (History)
2 users (show)

Is this bug a regression?: ---
Last known good build:

Notice (2018-05-24): bugzilla.xamarin.com is now in read-only mode.

Please join us on Visual Studio Developer Community and in the Xamarin and 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 Links.

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.

Related Links:

Description Ian 2011-09-16 15:33:17 UTC
MonoTouch 4.1.1

If there is a space in the phone number , the following will crash an iPad.

NSUrl url = NSUrl.FromString ("tel://1800 023 009");
if (UIApplication.SharedApplication.CanOpenUrl (url))
	UIApplication.SharedApplication.OpenUrl (url);
Comment 1 Sebastien Pouliot 2011-09-17 10:46:45 UTC
NSUrl url = NSUrl.FromString ("tel://1800 023 009");

returns 'null' if an URL is invalid. That in turn cause 

if (UIApplication.SharedApplication.CanOpenUrl (url))

to throw an ArgumentNullException. That differs a bit from using:

NSUrl url = new NSUrl ("tel://1800 023 009");

which returns an "empty" NSUrl instance, which will return 'false' from CanOpenUrl. I'll look if there was a reason for this different behavior between the two cases (i.e. the former is using URLWithString, while the later use InitWithString selector).
Comment 2 Sebastien Pouliot 2011-09-17 11:27:21 UTC

URLWithString: <quote>Return Value: An NSURL object initialized with URLString. If the string was malformed, returns nil.</quote>

initWithString: <quote>Return Value: An NSURL object initialized with URLString. If the string was malformed, returns nil.</quote>

Since no constructor can return null, MonoTouch NSUrl .ctor return an 'empty' managed instance (i.e. where the Handle is 0 because no native instance exists).

If not a big fan of returning non-null for invalid values used in NSUrl.FromString since this can break existing applications (checking for null but not for 'empty' instances) and create a mismatch with Apple documentation (a common fallback when MonoTouch documentation is not complete enough). However I'll look how other similar cases are handled inside MonoTouch to ensure our own API are consistent.

In the mean time, for existing releases of MonoTouch, you should add a null check on the result from NSUrl.FromString. Even if we change its behavior in the future (to return non-null, like the .ctor) your code would still work with the null check (as long as you still call CanOpenUrl). e.g.

NSUrl url = NSUrl.FromString ("tel://1800 023 009");
if ((url != null) && UIApplication.SharedApplication.CanOpenUrl (url))
    UIApplication.SharedApplication.OpenUrl (url);

Let me know if this can fix your present issue, i.e. I assume your crash is related to the uncatched ArgumentNullException I got locally, but if you get something else then this will need more investigation. Thanks!
Comment 3 Sebastien Pouliot 2011-10-06 15:40:23 UTC
Fixed in 3d3a98f76f909ba58b4f2207ef83ecaa0c1803cb

Future releases of MonoTouch will accept a null value inside CanOpenUrl so it won't matter if the 'bad' URL was created using the .ctor (valid instance, null handle) or the FromString (which returns null). That should make it easier (and more consistent) while coding.