Open Johennes opened 5 months ago
This is fixed for me as of 0.4.13
Oh, brilliant! Closing this out then.
I'm still seeing this on 0.5.0 actually.
@Johennes could you confirm which locale (country + language) are you using in your device/for the app, if they're different? The 'linkification' of text messages uses an Android library that relies on locale, and I can't reproduce the issue with en_US
.
Using schildinext based on 0.4.16. android "languages" are 1) en_US and 2) de_DE.
Using schildinext based on 0.4.16. android "languages" are 1) en_US and 2) de_DE.
Huh, that's weird. They're the same I have in my test device:
Although I'm testing it on v0.5.1
. Also, I don't know if SchildiNext may have some different logic/post formatting for timeline messages.
I know it's kind of a pain but could you add links to some messages that have this issue, if they're public? Maybe they need to have some specific format.
I can confirm I can't reproduce it on 0.5.1 (develop)
with en_US
and de_DE
locales:
This is the linked message, but I don't see which content could be linkified (maybe the user123?):
Could any of the affected users download a nightly EX version and test if it's working for them so we can confirm if the issue can be closed?
I tried 0.5.1-nightly (40005010) and am seeing the same issue:
My languages are:
Ah, my bad, the behaviour changes based on the TelephonyManager
outputs, that is: the phone number format expected for the country your SIM cards is registered in, if I'm not mistaken, so that's why I couldn't reproduce it even when changing the locale. From a related issue seen in the past:
Also, it was especially hard to debug because the issue was focused in phone number being linkified and the detection of those phone numbers depend on the region code returned by the TelephonyManager service, which will vary from one device to another. It's a lot easier to spot with emails, i.e.
I don't think there's an easy way to either test this on my end or modify the way the telephone links are detected... Maybe we could try iterating in the returned links and check whether they at least match a full number (so, non-letter character, a bunch of numbers, then another non-letter characters)... either that or we need to move to a new linkification library like this one.
Maybe we could try iterating in the returned links and check whether they at least match a full number (so, non-letter character, a bunch of numbers, then another non-letter characters)
Something like that or maybe at least a minimum length? There are some public service phone numbers in Germany that are only 3 numbers. Any regular number I've seen so far was a lot longer though. With very short numbers, the advantage of tel-linking over manually punching in the number also seems rather small. So I think we wouldn't really lose much value if we'd only tel-link, say, >=7 digits.
Just checked Signal and it does have the exact same problem for me. Ironically I've never noticed this, maybe because my conversations there are less technical and don't commonly include numbers or maybe because Signal's linking style is a lot more subtle than the one in Element X. 🤔
It does really annoy me on Element X for some reason though. 🙈
Steps to reproduce
Outcome
What did you expect?
No link
What happened instead?
A call link
Your phone model
Pixel 6
Operating system version
14
Application version and app store
0.4.12
Homeserver
matrix.org
Will you send logs?
No
Are you willing to provide a PR?
Yes