[go: nahoru, domu]

Page MenuHomePhabricator

Prevent Safari from creating phone links for numbers in format ###-####
Closed, ResolvedPublic

Description

Writing numbers in the format: ###-#### causes Safari on iOS to treat them as a phone link. This format would typically be used for year ranges, e.g. 612-1200.

Apple has an article about this here: https://developer.apple.com/library/archive/featuredarticles/iPhoneURLScheme_Reference/PhoneLinks/PhoneLinks.html

Possible solutions might be to hack around it with JS (if possible?), or perhaps disabling default parsing with <meta name = "format-detection" content = "telephone=no">, and require explicitly defining when something should be parsed as a telephone number using <a href="tel:1-408-555-5555">1-408-555-5555</a>.

Reported at: https://en.wikipedia.org/w/index.php?title=Wikipedia:Village_pump_(technical)&oldid=965297714#Phoning_Germany

browser-call.jpeg (1×828 px, 428 KB)

Event Timeline

Xaosflux subscribed.

See also T55315 where this was resolved, but only for editing page on visual editor.

It's not clear to me that the fix in T55315 was deliberate - rather, it seems to have been a case of "something that happened fixed it", as there's no associated patch (although I could very easily be wrong on that, @Jdforrester-WMF will know more!)

If people think it's a good idea so to do, I'm happy to get a patch sorted to give an option on LocalSettings.php, similar to $wgDefaultRobotPolicy, that would allow that meta tag to be added (so enwiki could add it, but we could leave it off on wikivoyage, for instance).

If Safari tries to be smart on random websites out there, e.g. converting years like 2020-2021 into a tel: link though it is no tel: link in the source of the page, then I'd say that a bug report should be filed in Safari's issue tracker instead to allow turn this off in Safari.

Personally I don't think we want to insert <meta name = "format-detection" content = "telephone=no"> into every single page we ship.

Possible solutions might be to hack around it with JS

Date ranges are best written with endash: https://www.thepunctuationguide.com/en-dash.html
Matching dates and replacing - with &ndash; or &#x2013; would be a workaround for that Safari bug and semantically more correct.

This is the way that the web is headed in general from what I can see, whether we like it or not. Edge and IE11+ on Win8+ like to do the same thing, and whilst some are confused by it, it's been there for a while and doesn't seem like there's any much momentum to remove it - especially as the mobile web becomes more dominant.

Possible solutions might be to hack around it with JS

Date ranges are best written with endash: https://www.thepunctuationguide.com/en-dash.html
Matching dates and replacing - with &ndash; or &#x2013; would be a workaround for that Safari bug and semantically more correct.

At the original discussion, an endash is what's being used, and the link is still happening.

At the original discussion, an endash is what's being used, and the link is still happening.

Bummer. Would have been a neat solution.
As people say there, it's unlikely Safari would fix this in a reasonable timeframe.

It's not clear to me that the fix in T55315 was deliberate - rather, it seems to have been a case of "something that happened fixed it", as there's no associated patch (although I could very easily be wrong on that, @Jdforrester-WMF will know more!)

I vaguely remember that Apple fixed it upstream for us (in the contenteditable context). Note that we found and chose to reject the "fix" of adding a format-detection to every page in MediaWiki precisely because this would disable the functionality on all read pages. If consensus is that this should never be used on any page, we can carry on with that trivial patch, but I'm not sure how we'd determine whether that's the right way to go.

@Jdforrester-WMF @Aklapper if the functionality is indeed undesirable I'm not sure if it matters whether Apple fix this on their end (which, ultimately, I'd think any 'fix' would require removal of the feature, since it's hard to determine whether 900-1200 is a phone number or a year) or if MediaWiki does just for its software using the meta tag. (I believe this tag is only recognised by Safari for these purposes, but I could be wrong). Of course, links can still be formatted as tel if they're explicitly formatted as such, and via the use of a template it'd be neater than the a tag everywhere.

I think it's at least worth considering the option for some wikis. enwiki has far more usages of 900-1200 (year) than it does telephone numbers which people might actually want to dial (at a glance, I can only see dummy telephone numbers listed on articles, e.g. 555-5555). Aware some wikis like WikiVoyage may be different, and introducing a default requirement to explicitly state the telephone number may not be an ideal change, but making it opt-out-able doesn't seem to be too harmful?

I vaguely remember that Apple fixed it upstream for us (in the contenteditable context). Note that we found and chose to reject the "fix" of adding a format-detection to every page in MediaWiki precisely because this would disable the functionality on all read pages. If consensus is that this should never be used on any page, we can carry on with that trivial patch, but I'm not sure how we'd determine whether that's the right way to go.

Yeah, it makes sense that contenteditable shouldn't really ever have a clickable telephone number - I can only imagine the pain of trying to move cursors in content, and accidentally calling phones!

As to determining consensus, I've started an RfC on VPT on enwiki to try and gain consensus one way or another on this change. If consensus is determined to be that the change is positive, I'll put together a patch; otherwise, we can close this as WONTFIX.

This fix really should be on the browser side, phone numbers are normally written with a hyphen ("-", 0x2D) while in articles such as the example above with date ranges we normally use the en-dash ("–", 0x2013). Apple probably shouldn't be doing phone number translations on en dashes.

As to determining consensus, I've started an RfC on VPT on enwiki to try and gain consensus one way or another on this change. If consensus is determined to be that the change is positive, I'll put together a patch; otherwise, we can close this as WONTFIX.

To be clear, we're talking about making a change for all thousand Wikimedia-hosted wikis, plus the tens of thousands of public and private MediaWiki sites hosted by everyone from NASA and the CIA to Fandom and the W3C. I'm not sure the views of enwiki alone are the right venue for this kind of decision, sorry.

To be clear, we're talking about making a change for all thousand Wikimedia-hosted wikis, plus the tens of thousands of public and private MediaWiki sites hosted by everyone from NASA and the CIA to Fandom and the W3C. I'm not sure the views of enwiki alone are the right venue for this kind of decision, sorry.

Are we? I wasn't proposing that this be made default behaviour:

If people think it's a good idea so to do, I'm happy to get a patch sorted to give an option on LocalSettings.php, similar to $wgDefaultRobotPolicy, that would allow that meta tag to be added (so enwiki could add it, but we could leave it off on wikivoyage, for instance).

I should have made it clearer that I think the default would be not having the meta tag, sorry. It could be toggled on in LocalSettings as needed.

I think this is a good idea, as long as it is configurable via LocalSettings. I'm not entirely sure about what the default value for mediawiki should be however. On the one side, maybe sites currently depend on on this and will be surprised if it suddenly disappears, but also having mw.org defaults out of sync with wmf defaults, tends to be annoying for system adminitrators as well, so.....

This fix really should be on the browser side, phone numbers are normally written with a hyphen ("-", 0x2D) while in articles such as the example above with date ranges we normally use the en-dash ("–", 0x2013). Apple probably shouldn't be doing phone number translations on en dashes.

Created a bug on WebKit's Bugzilla for this as well.

Created a bug on WebKit's Bugzilla for this as well.

It would be extremely welcome to share links so other people can also check. :)
https://bugs.webkit.org/show_bug.cgi?id=213836

Created a bug on WebKit's Bugzilla for this as well.

I've been informed that this processing is done outside of WebKit, so the issue would need to be reported at https://developer.apple.com/bug-reporting/

Change 615294 had a related patch set uploaded (by TheDJ; owner: TheDJ):
[mediawiki/core@master] Disable Brower data detection for phonenumbers.

https://gerrit.wikimedia.org/r/615294

Ive just created a quick patch. I personally think that changing the behavior is not a huge problem, as long as third parties can switch it back with a configuration option. But we can swap the default and override in wmf config, if ppl think it is safer.

Change 615294 abandoned by TheDJ:
[mediawiki/core@master] Disable browser data detection of phonenumbers

Reason:

https://gerrit.wikimedia.org/r/615294

@TheDJ curious why the patch was abandoned? Seems like it'd technically work?

Jdlrobson subscribed.

Webkit bug was declined as an Apple bug. Not sure what to do with this one. Is it still an issue? I don't have an iPhone so can't check.

Jdlrobson changed the task status from Open to Stalled.EditedJan 15 2021, 11:40 PM
Jdlrobson claimed this task.

Needs direction. Specifically an answer from @TheDJ on T256758#6496036

This bug should be declined in 6 months, if we don't have more context about that.

Needs direction.

From who exactly? There is a patch and I don't see what this task is stalled on by definition ("waiting for further input (e.g. from the task author or a third party like upstream) and can currently not be acted on").

I found this edit https://en.wikipedia.org/w/index.php?title=Dan_Rowan&diff=1007921857&oldid=1002484254&diffmode=source which I assume is related to this bug. I mention it here in case a recent example and direct-diff is useful.

The patch was abandoned so that others can feel free to pick it up and do not sit around waiting for me to follow up (which i generally wont, ive spent about 10 hours total on MediaWiki over the past year)

Pcoombe changed the task status from Stalled to Open.Jul 22 2021, 11:28 AM
Pcoombe subscribed.

Unstalling, given the comments. See also T116525 which is specifically about the problem of these making it through to edits, where there appears to have been an uptick recently.

Change 615294 restored by Jdlrobson:

[mediawiki/core@master] Disable browser data detection of phonenumbers

https://gerrit.wikimedia.org/r/615294

Change 615294 merged by jenkins-bot:

[mediawiki/core@master] Disable browser data detection of telephone numbers

https://gerrit.wikimedia.org/r/615294

Jdforrester-WMF renamed this task from Safari creates phone links for numbers in format ###-#### to Prevent Safari from creating phone links for numbers in format ###-####.Jul 26 2021, 10:05 AM
Jdforrester-WMF closed this task as Resolved.
Jdforrester-WMF assigned this task to TheDJ.

@Trizek-WMF would it be possible to update the description of this ticket with replication steps (I struggled to summarize the conversation on the wiki page)?

Interesting.. seems a bit as if Safari's content editable isn't respecting the setting ?

Opening the following links in iOS shows the problem (you do need to be in the visual editor, not the source editors.

https://en.m.wikipedia.org/wiki/User:TheDJ/sandbox_phonenumber
https://en.m.wikipedia.org/wiki/User:TheDJ/sandbox_phonenumber?venotify=created#/editor/all

Does anyone know if there is a Mobile interface specific flag on a url that I can use to force usage of the visual editor ? Otherwise I need to explain to apple engineers which buttons to push :)

Or.. perhaps its because we do some dom fragment loading before it is inserted into the document and therefor the fragment doesn't respect this document setting ?

btw. technically, this should probably be a separate ticket.. The original issue was about links added to pageview. This ticket is explicitly about tel links being added to the editor interface. The original issue is fixed.

btw. technically, this should probably be a separate ticket.. The original issue was about links added to pageview. This ticket is explicitly about tel links being added to the editor interface. The original issue is fixed.

It already was: T116525: Prevent iOS Safari and other browsers' plugins from converting numbers into `tel:xyz` links.