Page MenuHomePhabricator

VisualEditor: Safari on iPad converts numbers that resemble phone numbers to href=tel: links
Closed, ResolvedPublic1 Estimated Story Points

Description

Same as #51959, but it keeps hapenning on frwiki: some texts that look like telephone numbers are changed in <a href="tel:...">...</a>.

http://fr.wikipedia.org/w/index.php?title=Les_Visiteurs_(film,_1993)&diff=95954243&oldid=95559259

http://fr.wikipedia.org/w/index.php?title=Transformers_3_:_La_Face_cach%C3%A9e_de_la_Lune&diff=96093057&oldid=95089445


Version: unspecified
Severity: normal
OS: other
Platform: Other
See Also:
https://bugzilla.wikimedia.org/show_bug.cgi?id=51959

Details

Reference
bz53315

Event Timeline

I can't reproduce it on either page using Firefox 23 / Linux.

Do you know what OS/browser those editors were using?

May it be caused by a Skype plugin for the browser, that usually make those telephone-looking numbers into a clickable link to make a call through Skype?

http://stackoverflow.com/questions/3032427/how-to-prevent-phone-numbers-to-be-converted-into-skype-links

For the first one, iPad with Safari.
No answer for the seconde one.

Bug 51959 was also iPad/Safari and I've not seen any reports of it being reproducible on any other system so I've adjusted the bug summary accordingly.

This might be a bug in Safari rather than VE, but even if it is it would be useful for VE (or Parsoid?) to detect the changes and neutralise them. It is unlikely that Wikipedia would need href=tel: links but I can see they might be useful in environments like the contact pages on the Foundation wiki, so stripping such links completely mightn't be the optimal solution?

Hmmm, it seems I was close enough ;)

"In Safari on iOS, telephone number detection is on by default" according to [1]. There it says that adding <meta name="format-detection" content="telephone=no"/> would prevent that autolink feature, that may interfere with the content editable component of the editor.


[1] https://developer.apple.com/library/safari/featuredarticles/iPhoneURLScheme_Reference/Articles/PhoneLinks.html

(In reply to comment #4)

This might be a bug in Safari rather than VE, but even if it is it would be
useful for VE (or Parsoid?) to detect the changes and neutralise them. It is
unlikely that Wikipedia would need href=tel: links but I can see they might
be
useful in environments like the contact pages on the Foundation wiki, so
stripping such links completely mightn't be the optimal solution?

Isn't the <a> tag deactivated on the Foundation wiki also, as it is on Wikipedia ?
On Wikipedia, the <a href="tel:...">...</a> doesn't produce a link because MediaWiki renders the <a> tag as text.

Even if "tel:" was needed on any wiki, it would be better handled as an external link [tel:... ...] than as a <a> tag.

And, yes, I really think that VE/Parsoid should find a way to detect changes from browser extensions and neutralize them, otherwise it will be an endless battle to have every extension modified, updated, ...

(In reply to Jesús Martínez Novo (Ciencia Al Poder) from comment #5)

Hmmm, it seems I was close enough ;)

"In Safari on iOS, telephone number detection is on by default" according to
[1]. There it says that adding <meta name="format-detection"
content="telephone=no"/> would prevent that autolink feature, that may
interfere with the content editable component of the editor.


[1]
https://developer.apple.com/library/safari/featuredarticles/
iPhoneURLScheme_Reference/Articles/PhoneLinks.html

That URL is no longer valid. This is the new one:

https://developer.apple.com/library/ios/featuredarticles/iPhoneURLScheme_Reference/PhoneLinks/PhoneLinks.html

The answer appears to be to have:

<meta name = "format-detection" content = "telephone=no">

… in the <head> of the page. Unfortunately, we probably don't want to switch this off for all MediaWiki pages, so instead we will need to experiment to see if JS inserting it into there makes the behaviour go away.

So, James, is this what we are going to do, adding this line? Thanks.

(In reply to Elitre from comment #10)

So, James, is this what we are going to do, adding this line? Thanks.

Yes, experimentation as to what triggers Safari to break things, and what changes cause it to stop breaking, is needed.

On re-testing this is now fixed.