Gnome-shell-extension-gsconnect: SMS not being sent out via Samsung Galaxy S10, unless switched to legacy mode

[mandree]

Describe the bug

I am using a fully-updated Samsung Galaxy S10 (German) with Fedora Linux 31. I can read all SMS on the device thorugh GSConnect. When I attempt to send an SMS, the text appears in the Messages app on the phone, but reports an error sending. Re-sending does not work either. I have two workarounds:

1. in the Messages App on the phone, tap on the (!) emblem next to the failed message, click "Bearbeiten" = Edit, then send.
2. alternatively, reconfigure the SMS module of GSConnect to use legacy SMS support, then I don't read the message history, but can successfully send out SMS via the S10.

Steps To Reproduce:

1. couple GSConnect to KDE-Connect on the Samsung smartphone
2. open SMS/Messages app in GSConnect
3. Type SMS and send it
4. see the (!) emblem and failed.

Expected behavior

SMS should be sent out from "normal" Messages component of GSConnect.

Screenshots

-

Support Log

Please generate a support log (Instructions) and paste any messages related to this issue between the two ``` lines below.

GSConnect Version: 33
GSConnect Install: user
GJS: 15807
XDG_SESSION_TYPE: x11
GDMSESSION: gnome

(the journalctl log did not contain anything related and was omitted)

System Details (please complete the following information):

• GSConnect version: 33
  
  
  
  • Installed from: GNOME Extensions website
  
  
• GNOME/Shell version: 3.34
• Distro/Release: Fedora 31

GSConnect environment (if applicable):

• Paired Device(s): Xperia XZ1 compact (G8441), Galaxy S10
• KDE Connect app version: 1.14.2
• Plugin(s): [if the issue only occurs when using certain plugin(s)]

Additional Notes:

-

[andyholmes]

Hi, could you please generate a support log while:

• sending an SMS in "regular" mode
• sending an SMS in "legacy" mode

These two methods send messages the same way, so should be both working or not working. Just leave the dialog open while you send, then give it a few seconds and close to see the logs during that period.

[mandree]

Sorry for not providing it right away, I misread the instructions for the support log first time.

I have punched out useless information and redacted the deviceID, not knowing if it's identifying info. Obviously I've redacted my phone number, too.
log.txt attached

The "should be same" but relevant difference is in the phoneNumber field:

• regular SMS mode sends to phone number "49..." (without leading + character), this is 22:16:59...22:17:11 i. e. first in the log
• legacy SMS mode sends to phone number "+49..." (including + character). This is around 22:17:48.

I've toyed around with the Samsung Messages app on the phone, and found that editing the failed message text will fill the "+" even though I cannot edit the number. The phone directory contains the number with leading +, and it shows in the message editor windows in either case.

[andyholmes]

Thank for the log, that does seem to be the only difference.

I had a quick look and didn't see any difference between the way phone numbers are handled, but I expect somewhere we're passing back the normalized form of the phone number (we use those for number matching).

I'll have another look soon, to see if I can track down where/why that's happening. Are these both "reply" situations, or are they "select a contact & send"? It may be in one case the number is coming from the address book, and other time the message.

[mandree]

Both were "new message" situations, as in open, pick contact, write message.

[RicardoEPRodrigues]

Hello,

I also have this issue (using an S10e), I changed the APK of KDE connect to add the leading character, but I think this is an issue with GSConnect.

I don't know how to debug with GJS, but I think that the number that goes to KDE Connect is the output of toPhoneNumber instead of the original number. I found the following files relevant:

https://github.com/andyholmes/gnome-shell-extension-gsconnect/blob/c2b12f767731c4f4665b30df67a1550f29e49ca5/src/service/__init__.js#L168

https://github.com/andyholmes/gnome-shell-extension-gsconnect/blob/c2b12f767731c4f4665b30df67a1550f29e49ca5/src/service/ui/messaging.js#L517

https://github.com/andyholmes/gnome-shell-extension-gsconnect/blob/c2b12f767731c4f4665b30df67a1550f29e49ca5/src/service/plugins/sms.js#L376

Can someone tell me how to debug with breakpoints GJS? Is there an IDE?

[andyholmes]

I don't know how to debug with GJS, but I think that the number that goes to KDE Connect is the output of toPhoneNumber instead of the original number.

That's possible. It would mean the contact provider is modifying contact data when storing or retrieving phone numbers, which it shouldn't do.

Can someone tell me how to debug with breakpoints GJS? Is there an IDE?

There are two ways to debug a GJS application:

1. Using gdb, add breakpoints with imports.system.breakpoint(); and run the service with gdb --args gjs daemon.js
2. Using GJS's built-in debugger, by running gjs -d daemon.js

The second option will make it easier to work with the JavaScript code, but is limited and buggy when compared to gdb. Using gdb on the other hand, will take more work and probably require some experience with C, GLib and GDB.

There is also a built-in trace function in GSConnect: debug(). This will take an Error or a string and print a reasonable trace, but requires the key at /org/gnome/shell/extensions/gsconnect/debug to be set to true:

$ dconf write /org/gnome/shell/extensions/gsconnect/debug true

[RicardoEPRodrigues]

Ok, so after a morning looking into this (and so debug() here and there) I found no issue in GSConnect.

Here is my input and @mandree can you check if this solves your issue?

The issue is a corrupt conversation stored on the phone. I deleted the conversation and started a new one and it now works just fine. My guess is that the message thread on my phone had an issue and corrupted a contact, so instead of storing +XXX YYY YYY YYY it was storing XXX YYY YYY YYY (XXX is the country code). It worked on the phone, but not on GSConnect. From the logs, I could see that I only had one contact with this issue.

From the code I read, the message thread in GSConnect gives preference to the contact in it and not the one in the Contacts database. GSConnect could be improved by always using the contact from Contacts and not from the message thread. Because the message thread stored XXX YYY YYY YYY it would match with the correct contact but would send an incorrectly SMS.

Hope this helps fix this issue!

[mandree]

@RicardoEPRodrigues apparently that helps, for some reason however, the conversation "with myself" no longer synchs with GSConnect after deleting it. Other conversations do synch.

[mandree]

@RicardoEPRodrigues apparently that helps, for some reason however, the conversation "with myself" no longer synchs with GSConnect after deleting it. Other conversations do synch.

After more playing with this, it just does not seem practical to erase the entire message history just to send a fresh message out...

[andyholmes]

So after scratching my head for some time, I think I may have found the problem.

When you used the messaging window you selected a contact which opened an existing conversation, but conversation are grouped by thread ID, not by contact.

When the conversation was selected it took the phone numbers from the thread messages. While Samsung phones seem to have an issue sending messages without the + prefix, they apparently think it's a swell idea to store them in the database without it.

This is pretty unfortunate because it means we'll have to look up a contact for each address, then loop back again to correct the input addresses. Not so efficient, but I should have a fix up shortly for testing.

[andyholmes]

Here is a ZIP with the proposed fix (Instructions). If you can confirm the fix works, I will merge it for the next release:

[email protected]

[mandree]

Unfortunately I am still on GNOME 3.34.5 (Fedora 31) and the update extension will not start or open the prefs there, I've tried both your zip archive as well as the unaltered master branch from Git (not that I'd expected it to make a difference).

I'll see if I can get a Fedora 32 test mustered and if its GNOME is new enough. The first line translates to "resource ... does not exist".

Aug 23 11:26:31 somehost.example.org gjs[587901]: Unable to load resource for composite template for type 'GSConnectPreferencesShortcutEditor': Die Ressource auf »/org/gnome/Shell/Extensions/GSConnect/ui/preferences-shortcut-editor.ui« existiert nicht
Aug 23 11:26:31 somehost.example.org gjs[587901]: gtk_widget_class_bind_template_child_full: assertion 'widget_class->priv->template != NULL' failed
Aug 23 11:26:31 somehost.example.org gjs[587901]: gtk_widget_class_bind_template_child_full: assertion 'widget_class->priv->template != NULL' failed
Aug 23 11:26:31 somehost.example.org gjs[587901]: gtk_widget_class_bind_template_child_full: assertion 'widget_class->priv->template != NULL' failed
Aug 23 11:26:31 somehost.example.org gjs[587901]: gtk_widget_class_bind_template_child_full: assertion 'widget_class->priv->template != NULL' failed
Aug 23 11:26:31 somehost.example.org gjs[587901]: gtk_widget_class_bind_template_child_full: assertion 'widget_class->priv->template != NULL' failed
Aug 23 11:26:31 somehost.example.org gjs[587901]: gtk_widget_class_bind_template_child_full: assertion 'widget_class->priv->template != NULL' failed
Aug 23 11:26:31 somehost.example.org gjs[587901]: JS ERROR: ReferenceError: _ is not defined
                                           @/home/mandree/.local/share/gnome-shell/extensions/[email protected]/service/plugins/sftp.js:12:5
                                           @/home/mandree/.local/share/gnome-shell/extensions/[email protected]/preferences/device.js:18:9
                                           @/home/mandree/.local/share/gnome-shell/extensions/[email protected]/preferences/service.js:11:7
                                           @/home/mandree/.local/share/gnome-shell/extensions/[email protected]/gsconnect-preferences:32:7
Aug 23 11:26:31 somehost.example.org gnome-shell[103094]: Script /home/mandree/.local/share/gnome-shell/extensions/[email protected]/gsconnect-preferences threw an exception

[mandree]

Fedora 32, GNOME 3.36.5 => success.

1. Cloned & installed from Git, confirmed that issue persists when responding to a conversation (outgoing message error due to missing leading +)
2. Cherry-picked cdcb418, reinstalled, restarted GNOME session, sent another message from the same conversation, success.

HOWEVER would that work if there was a conversation with someone who is not in the phone book?

[andyholmes]

Fedora 32, GNOME 3.36.5 => success.

Thanks a lot for testing that :)

HOWEVER would that work if there was a conversation with someone who is not in the phone book?

Probably not, since there's really no way to know what a phone number is supposed to be.

It looks like the source of the phone number KDE Connect is using is the only one available (Telephony.Sms.ADDRESS), so it seems like not being able to use the phone number from a message is ultimately a Samsung bug.

[mandree]

it seems like not being able to use the phone number from a message is ultimately a Samsung bug.

So possibly I might want to swap out the Samsung messages app for one that works then? It's android, after all...

[ferdnyc]

@mandree

There's always Android Messages. Which also has a companion web UI that, to be honest, renders GSConnect's SMS support a tad superfluous.

[mandree]

@ferdnyc indeed, but these web whatever hooks into Threema, Messages, WhatsApp usually consume ridiculous amounts of battery charge, I'm not going to use that regularly. But Google's Messages indeed does not apparently show the bug I was reporting here.

[ferdnyc]

@mandree Oh, sure, but right now you're constrained to using SMS on your local network, which probably means your phone is near a charger, right? :wink: Android Messages seems pretty well-behaved, I haven't seen any signs that it causes device activity except when the web UI is actually open in my browser. Everything's routed through Google's cloud so it's relatively lightweight. Probably chews up _less_ power when it's active than KDE Connect does, TBH.

[mandree]

Well... I think we're spinning off the topic here, so I'll skip that.

For fresh GNOME versions, the next GSConnect version will work around this Samsung bug as long as the correspondent is in my contact list, and everyone else can consider using Google's instead of Samsung's SMS app. Knowing the remaining limitations, good enough for me.