33

Is there any way to detect whether a mobile device is capable of making voice calls / SMS messages?

This is important when applying tel: and sms: links in a web page. It is not enough to merely detect mobile, since tablets can't make calls, iTouch can't make calls, etc.

I'm not interested in mobile detection hacks using device size, UA string detection, etc. I want to use feature detection to determine if the device is capable of voice calls / SMS text messaging. I'd love a universal solution, but am mainly interested in iOS / Android.

Kara
  • 6,115
  • 16
  • 50
  • 57
Jon Raasch
  • 3,703
  • 6
  • 30
  • 32
  • Relevant, but not really helpful: http://stackoverflow.com/questions/836777/how-to-detect-browsers-protocol-handlers – Yahel Aug 03 '11 at 20:25

2 Answers2

12

I havent seen an obvious way to see that sms: and tel: links get special treatment.

Update: @janogosteve below has confirmed there is currently no reliable feature detect. This looks undetectable.

Here's a comprehensive way to check this feature detect. (Read jangosteve comment below!)

  • make a test page with two of those links and a regular http link
  • grab the elements and then traverse all their properties, copy it all over to an object..
  • also getComputedStyle info for a bunch of details on them and throw that into an object as well
  • JSON.stringify( that stuff so you can deal with it later on)

Do the above on an iOS device and in desktop Safari/Chrome

Then JSON.parse them back into objects... and use https://github.com/NV/objectDiff.js to see if you can spot any differences at all.

Volker E.
  • 5,911
  • 11
  • 47
  • 64
Paul Irish
  • 47,354
  • 22
  • 98
  • 132
  • 4
    FYI, I spent considerable time doing exactly this. I've compared getComputedStyle properties, DOM element properties, and even click event properties, and have found no discernable differences between regular, mailto, tel, and sms links (across mobile Safari, Chrome, and Firefox, as well as desktop Safari, Chrome, and Firefox). It was a good idea, but ultimately fruitless. Just wanted to let anyone know who comes across this, as it wasn't a trivial task to go through the process to test this. – jangosteve Aug 14 '14 at 23:36
5

A new plot twist in this problem (as of Feb 2015) is that many desktop browsers now support click-to-call, however they won't auto-detect phone numbers.

So the nifty tricks floating around for sniffing out phone number auto-detection or touch capability, are now obsolete.

Mac OSX since Yosemite 10.9.2 has supported click-to-call with Facetime audio, and Windows 8 / IE11 does the same using Skype. Not sure about Chrome OS (Hangouts?). iPads use Facetime audio calls.

It looks like all web browsers from now onwards will support click-to-call. The question is really about how to prevent older browsers and desktop OS users from getting an error when clicking a tel: link.

I made a Javascript library to attempt to detect older desktop OS users that are before tel: link support, but it proved very problematic and complicated.

Right now my approach is either:

  • A) Leave it as a link for all users. Users without a call-capable browser will just have to suffer
  • B) Use a media query to hide the link styling for only desktop browser widths, assuming that most desktop users aren't going to be making calls from their desktop PC anyhow.
  • C) Skip the <a> tag and desktops altogether and let auto-detection do it's link magic on mobile devices

I'm not crazy about any of these solutions, but I'm opting for B until the browser support landscape changes in the future. That way I have control over the <a> tag, a desktop user can still click the phone # if they really want to, and I can swap easily in the future.

rwdsco
  • 691
  • 7
  • 8