[lnkForumImage]
TotalShareware - Download Free Software

Confronta i prezzi di migliaia di prodotti.
Asp Forum
 Home | Login | Register | Search 


 

Forums >

comp.lang.javascript

Javascript TEL: URI support detection

Richard Maher

5/17/2015 8:32:00 AM

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.
17 Answers

Evertjan.

5/17/2015 9:33:00 AM

0

Richard Maher <maher_rjSPAMLESS@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/rfc39... 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\")

5/18/2015 5:01:00 AM

0

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

5/18/2015 10:54:00 AM

0

On 5/18/2015 1:01 PM, Michael Haufe (TNO) wrote:
> 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
>

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\")

5/18/2015 3:53:00 PM

0

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_q...
[2] <https://developer.mozilla.org/en-US/docs/Web/CSS/Attribute_sel...

Richard Maher

5/19/2015 1:13:00 PM

0

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>

Michael Haufe (\"TNO\")

5/19/2015 9:08:00 PM

0

On Tuesday, May 19, 2015 at 8:13:20 AM UTC-5, Richard Maher wrote:
> 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>


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

5/20/2015 10:10:00 PM

0

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

5/31/2015 5:12:00 AM

0

On 5/21/2015 6:10 AM, Richard Maher wrote:
> 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.
>

Hi Michael,

The good news about your iFrame strategy is at least we can achieve
uniformity with silent failures to CALL/MAIL.

What I have done in the code below is demonstrate how to receive one
(and only one FireFox what a nightmare! preventDefault() is anti-logic)
BeforeUnload event when an attempt is made to phone/mail. )Opera
provides additional failure ALERT)

I'm guessing, (will try now) that I can wait N secs after the
beforeunload event and if it hasn't been cancelled by my
VisibilityChange event on the main window then that protocol is not
supported. Good enough?

Cheers Richard

<!DOCTYPE html>
<html>
<head>
<style type="text/css">

iframe
{
display: none;
width: 0px;
height: 0px;
}

</style>
</head>

<body onunload="console.log('Bye');" onblur="console.log('*blur');"
onload="load();">
<a id="anchor" href="#" target="output" onclick="myFunction()">
<button >Replace document</button>
</a>
<div id="fred"></div>

<script>

var cnt = 0;
var myW, out;

function load() {
document.addEventListener("visibilitychange", vc);
out = document.createElement("iframe");
out.addEventListener("load",fLoad);
out.name = "output";
out.src = "about:blank"
document.body.appendChild(out);
}

function vc() {
cnt++;
document.getElementById("fred").innerHTML="Visibility change"+cnt;
}

function fLoad() {
out.contentWindow.addEventListener("unload",fUnLoad);
out.contentWindow.addEventListener("beforeunload",fBeforeUnLoad);
console.log("*loaded");
}

function fUnLoad() {
out.contentWindow.removeEventListener("unload",fUnLoad);
setTimeout(resetx, 0);
console.log("*unloaded");
}

function resetx() {
out.src = "about:blank"
}

function fBeforeUnLoad(e) {
out.contentWindow.removeEventListener("beforeunload",fBeforeUnLoad);
setTimeout(reAdd, 0);
console.log("*beforeunload");
return;
}

function reAdd(){
out.contentWindow.addEventListener("beforeunload",fBeforeUnLoad);
}

function hndlr(e) {
var msg = "Cannot make calls message\ncurrentTraget =
"+e.currentTarget.location+"\ntarget = "+e.target.URL;
(e || window.event).preventDefault();
return;

(e || window.event).returnValue = msg;
return msg;
}

function myFunction() {
try{
document.getElementById("anchor").href="tel:+61123";
return;
} catch (e) {alert("e is "+e);}
}

</script>

</body>
</html>

Richard Maher

6/1/2015 10:52:00 AM

0

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\")

6/11/2015 1:50:00 AM

0

On Monday, June 1, 2015 at 5:52:32 AM UTC-5, Richard Maher wrote:
> 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.

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

(isProtocolHandlerRegistered)

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