Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.javascript > #27707 > unrolled thread

Javascript TEL: URI support detection

Back to article view | Back to comp.lang.javascript

Contents

  Javascript TEL: URI support detection Richard Maher <maher_rjSPAMLESS@hotmail.com> - 2015-05-17 16:32 +0800
    Re: Javascript TEL: URI support detection "Evertjan." <exxjxw.hannivoort@inter.nl.net> - 2015-05-17 11:32 +0200
      Re: Javascript TEL: URI support detection Richard Maher <maher_rjSPAMLESS@hotmail.com> - 2015-05-17 19:12 +0800
        Re: Javascript TEL: URI support detection Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2015-05-19 21:59 +0200
    Re: Javascript TEL: URI support detection "Michael Haufe (TNO)" <tno@thenewobjective.com> - 2015-05-17 22:01 -0700
      Re: Javascript TEL: URI support detection Richard Maher <maher_rjSPAMLESS@hotmail.com> - 2015-05-18 18:53 +0800
        Re: Javascript TEL: URI support detection "Michael Haufe (TNO)" <tno@thenewobjective.com> - 2015-05-18 08:53 -0700
          Re: Javascript TEL: URI support detection Richard Maher <maher_rjSPAMLESS@hotmail.com> - 2015-05-19 21:13 +0800
            Re: Javascript TEL: URI support detection "Michael Haufe (TNO)" <tno@thenewobjective.com> - 2015-05-19 14:08 -0700
              Re: Javascript TEL: URI support detection Richard Maher <maher_rjSPAMLESS@hotmail.com> - 2015-05-21 06:10 +0800
                Re: Javascript TEL: URI support detection Richard Maher <maher_rjSPAMLESS@hotmail.com> - 2015-05-31 13:12 +0800
                  Re: Javascript TEL: URI support detection Richard Maher <maher_rjSPAMLESS@hotmail.com> - 2015-06-01 18:52 +0800
                    Re: Javascript TEL: URI support detection "Michael Haufe (TNO)" <tno@thenewobjective.com> - 2015-06-10 18:49 -0700
                      Re: Javascript TEL: URI support detection Richard Maher <maher_rjSPAMLESS@hotmail.com> - 2015-06-13 08:15 +0800
                        Re: Javascript TEL: URI support detection Richard Maher <maher_rjSPAMLESS@hotmail.com> - 2015-06-22 06:07 +0800
                          Re: Javascript TEL: URI support detection Richard Maher <maher_rjSPAMLESS@hotmail.com> - 2015-06-22 06:08 +0800
                          Re: Javascript TEL: URI support detection "Michael Haufe (TNO)" <tno@thenewobjective.com> - 2015-06-24 14:09 -0700
                            Re: Javascript TEL: URI support detection Richard Maher <maher_rjSPAMLESS@hotmail.com> - 2015-06-25 18:54 +0800
                              Re: Javascript TEL: URI support detection "Michael Haufe (TNO)" <tno@thenewobjective.com> - 2015-06-25 06:40 -0700
                                Re: Javascript TEL: URI support detection ittsmith1@gmail.com - 2015-07-20 18:57 -0700

#27707 — Javascript TEL: URI support detection

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.

[toc] | [next] | [standalone]

#27709

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/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)

[toc] | [prev] | [next] | [standalone]

#27716

On 5/17/2015 5:32 PM, Evertjan. wrote:
> 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/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
>
>

[toc] | [prev] | [next] | [standalone]

#27761

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.

[toc] | [prev] | [next] | [standalone]

#27726

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

[toc] | [prev] | [next] | [standalone]

#27728

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.

[toc] | [prev] | [next] | [standalone]

#27732

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>

[toc] | [prev] | [next] | [standalone]

#27757

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>

[toc] | [prev] | [next] | [standalone]

#27762

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)

[toc] | [prev] | [next] | [standalone]

#27782

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.

[toc] | [prev] | [next] | [standalone]

#27933

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>

[toc] | [prev] | [next] | [standalone]

#27952

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.

[toc] | [prev] | [next] | [standalone]

#28077

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-handlers>

[toc] | [prev] | [next] | [standalone]

#28094

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

[toc] | [prev] | [next] | [standalone]

#28136

On 6/13/2015 8:15 AM, Richard Maher wrote:
> 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

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 :-(

[toc] | [prev] | [next] | [standalone]

#28137

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

[toc] | [prev] | [next] | [standalone]

#28154

On Sunday, June 21, 2015 at 5:07:25 PM UTC-5, Richard Maher wrote:
> On 6/13/2015 8:15 AM, Richard Maher wrote:
> > 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
> 
> 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 :-(

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?".

[toc] | [prev] | [next] | [standalone]

#28158

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 :-)

[toc] | [prev] | [next] | [standalone]

#28160

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.

[toc] | [prev] | [next] | [standalone]

#28455

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)

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.javascript

csiph-web