Tel links with spaces do not work
Reported by
eric.m.o...@gmail.com,
Apr 6 2016
|
|||||||||
Issue descriptionUserAgent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_11_3) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/49.0.2623.110 Safari/537.36 Example URL: https://jsbin.com/huhiyo Steps to reproduce the problem: 1. Go to JSBin 2. Click on all three links, observe behavior What is the expected behavior? 1. The first link (with spaces) should do nothing/not work. 2. The second and third links (hyphen and no spaces) should prompt click to call protocol handlers. What went wrong? Tel links with spaces in them do not get passed to the protocol handler on click. Does it occur on multiple sites: Yes Is it a problem with a plugin? No Did this work before? No Does this work in other browsers? N/A Chrome version: 49.0.2623.110 Channel: stable OS Version: OS X 10.11.3 Flash Version: Shockwave Flash 21.0 r0 <3
,
Apr 7 2016
,
Apr 7 2016
Ah, my apologies, I didn't write that properly: the first link with spaces *should* prompt tel protocol handlers. (I was saying that the expected *broken behavior* is that the link should not work, my bad)
,
Apr 7 2016
Separately, I can confirm that this is not a bug on Windows 7 Chrome.
,
Apr 8 2016
Thank you for providing more feedback. Adding requester "kojii@chromium.org" for another review and adding "Needs-Review" label for tracking. For more details visit https://sites.google.com/a/chromium.org/dev/issue-tracking/autotriage - Your friendly Sheriffbot
,
Apr 11 2016
,
Apr 11 2016
,
Apr 11 2016
,
Apr 11 2016
,
Apr 11 2016
This is caused by LSGetApplicationForURL returning error for numbers with spaces (via GetApplicationNameForProtocol). We could try to normalize tel: URLs but maybe there is a better way.
,
Apr 11 2016
Looks like the newer LSCopyDefaultApplicationURLForURL api handles these numbers just fine.
,
Apr 11 2016
^ Scratch that, LSCopyDefaultApplicationURLForURL doesn't work with spaces either (it was me testing incorrectly)
,
Apr 12 2016
According to section 2.5.3 of http://www.ietf.org/rfc/rfc2806.txt spaces shouldn't be used in tel: URLs. Is there some reason why you want to use them?
,
Apr 13 2016
,
Apr 13 2016
I believe I have seen it as a convention in displaying international phone numbers (a mix of dashes and spaces) and found it odd that Windows Chrome can parse tel links with spaces and that Mac Chrome cannot. Admittedly, the real reason this was reported is that I am working on a project maintaining hundreds of sites with different configurations; *some* of the tel links on these sites have spaces in them. I was apprehensive towards manually fixing so many of these tel links, so I investigated the issue further. After some investigation and discovering it was only a problem on Mac Chrome, I was curious to see if this was intentional and whether or not the Chromium group would be interested in fixing it. Either way, thank you for your help so far :)
,
Apr 14 2016
OK cool. This is not an intentional behavioral thing from Chrome, but is just an outcome of the way the different platforms handle these links. And I'm sure you know this, but there is nothing stopping you from displaying phone numbers with spaces, e.g. via <a href="tel:1-800-555-5555">1 800 555 5555</a>.
,
Apr 15 2016
"..is just an outcome of the way the different platforms handle these links." I see, thank you :) |
|||||||||
►
Sign in to add a comment |
|||||||||
Comment 1 by kojii@chromium.org
, Apr 7 2016