Javascript TEL: URI support detection

[Richard Maher]

I've googled around and cannot find a reliable way to detect Browser and
Device support for "TEL:" URIs with Javascript.

If it's a mobile phone then the anchor link works as expected. But if
it's a PC without telephone and voice capability it just fails silently :-(

What solution(s) are you using?

Cheers Richard Maher

PS. As usual, hopefully Evertjan can keep clutching Thomas' big pointed
ears with nurse Ratchet reigning them in while constructive responses
arrive.

[Evertjan.]

Richard Maher <maher_rj...@hotmail.com> wrote on 17 mei 2015 in
comp.lang.javascript:

> I've googled around and cannot find a reliable way to detect Browser and
> Device support for "TEL:" URIs with Javascript.

<https://www.ietf.org/rfc/rfc3966.txt> see 7.3. Why "tel"?

Did you try "callto:"

> If it's a mobile phone then the anchor link works as expected. But if
> it's a PC without telephone and voice capability it just fails silently
> :-(
>
> What solution(s) are you using?

It is only called upon onclick, so it probly is outside the reach of page
javascript

And it is probably even ment that way, because it would be a breach of
security to have javascript know if a phone is connected that way.

[Otherways, you could load an image on failure letting the server know]

> PS. As usual, hopefully Evertjan can keep clutching Thomas' big pointed
> ears with nurse Ratchet reigning them in while constructive responses
> arrive.

Wasn't that constructive?

I for one would want to tap Thomas'es wide knowledge,
rather taking his possible wise-guy-ness for just what it is.

--
Evertjan.
The Netherlands.
(Please change the x'es to dots in my emailaddress)

[Michael Haufe (TNO)]

On Sunday, May 17, 2015 at 3:32:18 AM UTC-5, Richard Maher wrote:
> I've googled around and cannot find a reliable way to detect Browser and
> Device support for "TEL:" URIs with Javascript.
>
> If it's a mobile phone then the anchor link works as expected. But if
> it's a PC without telephone and voice capability it just fails silently :-(
>
> What solution(s) are you using?

Short answer is that this is not possible by design. Long answer is guesswork and hackish:

All I could think of is to attach an onclick listener to the link(s), then when they are clicked on attach an onblur event to the window plus a short timer of say a couple seconds that will clean itself up.

If the window blurs, you can guess with some probability that some application registered to that protocol took control. If after a short period of time (mentioned above) nothing took window focus, assume protocol is not supported

[Richard Maher]

Interesting. I hadn't seen this anywhere before and I've looked :-(

I think your/our problem is although Chrome fails silently (all?) others
(phoneless desktops) appear to try and fail to redirect to "tel:1234".

Before reading your post I was starting to look at the ONBEFOREUNLOAD
event as a way of offering the user an explanation that you shouldn't
really be here and you probably don't have a phone capability.

I think I was able to get Chrome to fail with window.location= and some
sort of cross-domain failure on the protocol (or was that FireFox?)

Anyway, thanks very much for the useful feed-back!

Cheers Richard Maher

PS. Please find a News Reader that wraps.

[Michael Haufe (TNO)]

On Monday, May 18, 2015 at 5:54:01 AM UTC-5, Richard Maher wrote:

> Interesting. I hadn't seen this anywhere before and I've looked :-(
>
> I think your/our problem is although Chrome fails silently (all?) others
> (phoneless desktops) appear to try and fail to redirect to "tel:1234".
>
> Before reading your post I was starting to look at the ONBEFOREUNLOAD
> event as a way of offering the user an explanation that you shouldn't
> really be here and you probably don't have a phone capability.
>
> I think I was able to get Chrome to fail with window.location= and some
> sort of cross-domain failure on the protocol (or was that FireFox?)
>
> Anyway, thanks very much for the useful feed-back!

There may be an alternative based on CSS depending on what your application is. For example, there exists a css media query supported on many browsers of the following form [1]:

@media handheld {
a[href^=tel:] {
display: none;
}
}
@media (not handheld) {
a[href^=tel:] {
display: none;
}
}

If someone has a handheld, assume tel support? (could fail on tablet though)

[1] <https://developer.mozilla.org/en-US/docs/Web/Guide/CSS/Media_queries>
[2] <https://developer.mozilla.org/en-US/docs/Web/CSS/Attribute_selectors>

[Richard Maher]

On 5/18/2015 11:53 PM, Michael Haufe (TNO) wrote:
I had seen media queries Max Height/Width but not "handheld". Look
either way it doesn't work and a desktop PC could still have a browser
supporting the TEL: protocol with a microphone. FireFox won't show the
message :-(

Below is a good first attempt IMHO but Chrome etc. has issues processing
a CALL directly without dialogue. I still think this is worth pursuing.

Come on! Jump in! the water's fine.

>
<!DOCTYPE html>
<html>
<body onunload="alert('bye');">

<button onclick="myFunction()">Replace document</button>

<script>
function hndlr(e) {
var msg = "Can't make calls message";
(e || window.event).returnValue = msg;
window.removeEventListener("beforeunload", hndlr);
return msg;
}

function myFunction() {
try{
window.addEventListener("beforeunload", hndlr);
myW = window.open("tel:123","_top");
return; //chrome
myW.document.open("text/html","replace");
myW.document.write("<p>hello</p>");
myW.document.close();
} catch (e) {alert("e is "+e);}
}
</script>

</body>
</html>

[Thomas 'PointedEars' Lahn]

Richard Maher wrote:

> On 5/17/2015 5:32 PM, Evertjan. wrote:
>> I for one would want to tap Thomas'es wide knowledge,
>> rather taking his possible wise-guy-ness for just what it is.
>

> Really "Janni-baby"?
>
> There is nothing quite so tragic as unrequited love :-(
> 5/12/2015: Pointles Prick "Re: smart phone with two camaras / can I
> select one?"
> > BTW, “Pointy” is not a proper way to address me, Janni-baby.
>
> >> Next thing the OP will ask us advice how to use a boyfriend.
>
> This latent homosexuality is getting on everyone's tits.

Thanks for reminding me again why you are still in my killfile (from which
you got out because I temporarily disengaged my filters for reading another
discussion). Not only are you an anti-social, address-munging complete
idiot, you are also an obnoxious homophobe. Now there’s redundancy.

JFYI: Being addressed as “Pointy”, I was referring to the relevant Monty
Python sketch, but apparently nobody got the joke.

--
PointedEars
FAQ: <http://PointedEars.de/faq> | SVN: <http://PointedEars.de/wsvn/>
Twitter: @PointedEars2 | ES Matrix: <http://PointedEars.de/es-matrix>
Please do not cc me. / Bitte keine Kopien per E-Mail.

[Michael Haufe (TNO)]

I've found something slightly productive in Firefox:

Set up an iframe: <iframe src="about:blank"></iframe>

Then have your "tel:" links target it. (I did mine through onclick listener)

wait about 1 second

then check to see if the contentDocument property of the iframe is null or not.

if contentDocument === null, then the frame navigated to the unsupported protocol page. If it did not, then about:blank is still accessible and contentDocument !== null

Chrome and IE seem to stay on about:blank though on success/fail (which is strange as you will get the error page if you open the link in a new tab)

[Richard Maher]

On 5/20/2015 5:08 AM, Michael Haufe (TNO) wrote:
>
> I've found something slightly productive in Firefox:
>
> Set up an iframe: <iframe src="about:blank"></iframe>

I'll have a look at your iframe idea.

Unfortunately phone-based Chrome, Firefox, and the Android browser all
trigger the beforeunload event before invoking the phone :-(

Safari on an iPad (without a phone) asks you to confirm +12345 Call/Cancel.

I guess they really don't want you to discobver if there is a phone there.

[Richard Maher]

On 5/31/2015 1:12 PM, Richard Maher wrote:
>
> The good news about your iFrame strategy is at least we can achieve
> uniformity with silent failures to CALL/MAIL.
>

Ok Chrome/Android and the Android browser will NOT activate the phone
app if the TARGET is an iFrame :-(

Opera, Firefox, and IE are fine.

I'm sick of worrying about non-phone-ready devices and how they handle
failure-to-launch. As they save in the classics "Fuck 'em!"

Having said that if someone has a reasonable way of detecting TEL: won't
work then by all means chime in.

[Michael Haufe (TNO)]

I think you're screwed until newer standards are better supported:

(isProtocolHandlerRegistered)

<https://html.spec.whatwg.org/#custom-handlers>

[Richard Maher]

On 6/11/2015 9:49 AM, Michael Haufe (TNO) wrote:
>
> I think you're screwed until newer standards are better supported:
>
> (isProtocolHandlerRegistered)
>
> <https://html.spec.whatwg.org/#custom-handlers>
>

That certainly would be handy! Thanks for the reference.

I think I can still help non-protocol supporting platforms by sticking
the anchor itself in your iFrame and have the mainbody replace the
content if it gets overwritten with a "Not Support" or "blank" page.

Thanks for your help.

Cheers Richard

[Richard Maher]

Well do you want the bad news or the bad news?

Chrome won't launch TEL: etc from and iframe regardless and the
is[Protocol|content]handlerRegistered looks design only for people
wanting to install their specific protocol handler. That is, it requires
a URL and their maybe a choice of several handlers servicing a URL protocol.

So back to giving up :-)

BTW if you click a TEL: anchor on IE desktop you get the "not supported"
page. Press BACK then click again and it just spins :-(

[Richard Maher]

Forgot to say, something like the "Plugins" collection on the Navigator
object would be noice.

[Michael Haufe (TNO)]

I think I would look into a different means to approach the problem. Something User Interface driven.

For example, if I was trying to create a video game and wanted to support DVORAK and QWERTY keyboards I wouldn't try to sniff to determine which a person was using, early in the process I would prompt: "Which keyboard layout are you using"

In your case, maybe something along the lines of: "Does your browser support making telephone calls?".

[Richard Maher]

On 6/25/2015 5:09 AM, Michael Haufe (TNO) wrote:
>
> I think I would look into a different means to approach the problem.

>Something User Interface driven.
>
> For example, if I was trying to create a video game and wanted to

>support DVORAK and QWERTY keyboards I wouldn't try to sniff to

>determine which a person was using, early in the process

>I would prompt: "Which keyboard layout are you using"
>
> In your case, maybe something along the lines of:

>"Does your browser support making telephone calls?".
>

Normally I would 100% agree. In this case though it is the Emergency
Number/button for Campus Security. I'm really trying to limit the number
of buttons and thought process and the user's heuristic success
processes :-)

You don't have to ask the user if their browser supports JAVA,
Javascript, voice-recognition, voice-synthesis, mozilla-apps,
web-sockets, web-workers etc. etc.

So for once Michael you've let me down by talking like Jannie Baby :-)

[Michael Haufe (TNO)]

On Thursday, June 25, 2015 at 5:54:13 AM UTC-5, Richard Maher wrote:

> Normally I would 100% agree. [...]

> So for once Michael you've let me down by talking like Jannie Baby :-)

If I was a lesser man, I'd either be flattered or insulted.

[itts...@gmail.com]

Excuse the interruption but your crew seems educated on a subject I'm new at. I am sick of proximity sensor not working properly on iphone and instead of paying 99 to Apple to fix there problem for them via a free app for all using the native app to detect call in progress and throwing up a nonfunctional page of my kids artwork (she would get a kick out of that) and since apple could nix the app at anytime, I started looking into html5 and javascript. I see how I could do it in native app (open c?) using the uri of phone but all I can reference for javascript is tel: phone#
I sense security won't let javascript do more than dial but wonder if every 3 seconds it tries and got an error code of call in progress it would know to maximize. Horrible waste of resource both in coding and processing but I am not allowed to jailbreak my phone (dial defender looks infinitely better than my solution) so I'm going down this route. I'm not a coder by trade but can do basic hello world in anything if motivated and am on a binge enough to ask complete strangers. It seems simple enough. One browser...Safari. One platform...ios. One job...if in call launch pic of unicorn. I'm fine with having to hit home to get back to call or make pass code on unicorn pic (or whatever, but I'm hoping I can max the screen to eliminate the call in progress indicator) sure, I could just launch static pic of unicorn (or calculator) prior to saying hello and found app out here in App Store that you launch to do nothing...but I would think I could auto detect via javascript.
I humbly ask for suggestions, thanks in advance. (Pending the answers my next stop is install an emulator and look at error codes returned when using tel: to see if hopefully sending a code once promos user to agree and that is persistent permission for every attempt thereafter and using special codes would sense call in progress but not tie up the line)

[Richard Maher]

On 5/17/2015 5:32 PM, Evertjan. wrote:

> Richard Maher <maher_rj...@hotmail.com> wrote on 17 mei 2015 in
> comp.lang.javascript:
>
>> I've googled around and cannot find a reliable way to detect Browser and
>> Device support for "TEL:" URIs with Javascript.
>
> <https://www.ietf.org/rfc/rfc3966.txt> see 7.3. Why "tel"?
>
> Did you try "callto:"

Did you try sticking your fucking head in a blender?

>
>
>> If it's a mobile phone then the anchor link works as expected. But if
>> it's a PC without telephone and voice capability it just fails silently
>> :-(
>>
>> What solution(s) are you using?
>
>

>> PS. As usual, hopefully Evertjan can keep clutching Thomas' big pointed
>> ears with nurse Ratchet reigning them in while constructive responses
>> arrive.
>
> Wasn't that constructive?
>
> I for one would want to tap Thomas'es wide knowledge,
> rather taking his possible wise-guy-ness for just what it is.

Really "Janni-baby"?

There is nothing quite so tragic as unrequited love :-(
5/12/2015: Pointles Prick "Re: smart phone with two camaras / can I
select one?"
> BTW, “Pointy” is not a proper way to address me, Janni-baby.

>> Next thing the OP will ask us advice how to use a boyfriend.

This latent homosexuality is getting on everyone's tits. You and Thomas
get a room and leave this newsgroup to people who want to discuss
Javascript. The clue's in the name! comp.lang.JAVASCRIPT
>
>