documenthandler - Safari incorrectly parses certain numeric values ​​so they disappear

[lina-sbk-gbg]

Some numerical values ​​in documents in documenthandler disappear in the mobile if you use Safari as web browser. They appear as they should in desktop and in, for example, Chrome on the mobile.

One guess is that Safari is trying to reinterpret the numbers into something special, which results in them disappearing.
When we tried to google the problem, it feels closely related to safari interpreting numbers into clickable phone numbers.

We need to find a solution that allows text in the format 6 000 - 12 000, for example, to be displayed correctly in Safari as well.

[jacobwod]

Could not reproduce.

Looks good on Safari 15, desktop as well as Safari mobile, iOS 15.5.

However, I notice that you get some warnings in the console. Most likely due to misformatted JSON files:

[jacobwod]

Hi @lina-sbk-gbg! I still can't reproduce. Can you provided the input you had in your JSON originally?

This:

…renders correctly:

[jacobwod]

OK, sorry - forgot to check in the mobile browser. Now I can see the error!

[jacobwod]

Documentation of the issue

It seem like space as thousands separator causes the problem. The following setup in Admin UI:

…renders like this on iOS:

What's most surprising is that although 8000 renders correctly, 8000-10000 and 8000 - 10000 don't.

Temporary work-around

As provided in the example above, using comma or dot as thousand separator seems to work this out. It is not a valid solution though, as thousands separator is locale-specific. In Swedish, for example, a space should be used instead. @lina-sbk-gbg

[jacobwod]

Now I found out what's going on. And it's an interesting find. 🤯 @Hallbergs: ideas?

Non iOS:

iOS:

[jacobwod]

Tried a proposed solution but it seems outdated, this didn't work:

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

[Hallbergs]

I guess safari is trying to be smart and display some numbers as telephone-numbers...

Seems like the proposed solution is

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

[Hallbergs]

Tried a proposed solution but it seems outdated, this didn't work:

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

😆

[jacobwod]

I really did try! 😭

This is for actual phone's dev console, connected to my browser via USB cable. No room for errors! 😉

[Hallbergs]

Maybe a zero width joiner somewhere in the number? (‍)

[jacobwod]

What puzzels me is that those paragraphs really become empty - not even a <a href="tel:……> going on. Just empty on mobile.

Desktop:

Mobile:

[jacobwod]

Maybe a zero width joiner somewhere in the number? (‍)

Saw that proposed solution. Would require some logic to get it right but it's doable.

But it'd be good to disable this auto-detection in the entire solution, so I'd really like to find a way.

[lina-sbk-gbg]

Since the different types of links in the documenthandler are given a special look, I guess other links are filtered out during parsing.
I think that's why it's blank instead of them being a clickable "phone number".

Maybe it is in the parser that Sweco built that you can recognize the link "<a href = \ "tel:..." and erase the link?

[jacobwod]

Maybe it is in the parser that Sweco built that you can recognize the link "<a href = \ "tel:..." and erase the link?
Yes @lina-sbk-gbg, you're correct.

I'm pretty certain by now that it is the iOS Safari thinks that these number sequences are phone numbers and creates a clickable link:

Next, this A-tag is parsed by the parser (as you see in the screenshot above). This specific tag lacks any of the data-* attributes (as it's not created in Admin UI by but Safari itself). So when Sweco's parser finds such an A-tag, it just drops it because it doesn't know what to do with it.

---

What's strange is that disabling it as by the documentation (the <meta> tag) has no effect:

[jacobwod]

OK, I have a solution. Coming up in a commit.

[Hallbergs]

OK, I have a solution. Coming up in a commit.

Nicely done!

[lina-sbk-gbg]

OK, I have a solution. Coming up in a commit.

👌👏 Thanks!