Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Bangle.js2 - Notification-strings in messages not displayed properly anymore #2380

Closed
kosi2801 opened this issue Jun 15, 2023 · 5 comments
Closed

Comments

@kosi2801
Copy link

Since a few builds of the Cutting Edge firmware the notifications are not properly displayed anymore on the Bangle.JS2 through the messaging application.

When a message contains an umlaut (eg german text) it is shown as two "Ä"-like characters, furthermore after the end of the message the same character is repeated until the end of the screen. See a screenshot below.

Since there have been commits a week ago around UTF-8 maybe there is some encoding- and line-ending mismatch still lingering somewhere.

I'm using the "Bangle.js Gadgetbridge" Android App from Google Store of version "0.74.0d-banglejs", commit e1c15a0a5. All relevant apps on the watch (Notifications, Messages, Message UI, Android Integration) are up to date according the App-Manager.
Currently the watch is on 2v18.36 cutting edge firmware.

edited_IMG_20230615_100849.

@gfwilliams
Copy link
Member

Ok, thanks! Yes, I think this is related - Gadgetbridge took a few shortcuts to try and transfer data as efficiently as possible - one of those was sending characters in the unicode range directly rather than encoding them with \u.... I'll have to do a new build of Gadgetbridge that doesn't do that.

But I'm actually struggling to reproduce using the Gadgetbridge debug button and sentences containing ü and ö. Do you think you could include a section of the Gadgetbridge log where one of these messages is sent? Or even better just find some text you can put in the Gadgetbridge debug menu (and then press send) that reproduces this and then paste it in here?

Also, do you have Text as Bitmaps or Transliteration turned on in device settings in Gadgetbridge?

@kosi2801
Copy link
Author

kosi2801 commented Jun 15, 2023

Thanks for the very quick response. Using the debug menu I could reproduce something similar, although not exactly the display as it comes from a GMail notification (ie only one strange char and no rubbish after the end of the notification). But maybe this can already be helpful.

"Text as Bitmaps" is turned on, "Transliteration" (if this is the english equivalent of "Sonderzeichen umschreiben") is turned off for all available languages. Should I try to change something there?

I also include the logfile I created for that result: gadgetbridge.log

The text I entered in the Message box was: Fön Kür Bär, which showed up the following way on the wrist:
edited_IMG_20230615_122007

Can I test or try something more?

@gfwilliams
Copy link
Member

Thanks! No need for Transliteration. This is really odd though.

If you connect with the Web IDE and when you're in the messages app and you paste in:

GB({t:"notify",id:1686681366,src:"Bangle.js Gadgetbridge",title:"",subject:"Fön Kür Bär",body:"Fön Kür Bär",sender:"Fön Kür Bär",tel:"Fön Kür Bär"})

Do you have any problems?

Or what about:

Bluetooth.inject([0x10,0x47,0x42,0x28,0x7b,0x74,0x3a,0x22,0x6e,0x6f,0x74,0x69,0x66,0x79,0x22,0x2c,0x69,0x64,0x3a,0x31,
0x36,0x38,0x36,0x36,0x38,0x31,0x33,0x36,0x36,0x2c,0x73,0x72,0x63,0x3a,0x22,0x42,0x61,0x6e,0x67,0x6c,
0x65,0x2e,0x6a,0x73,0x20,0x47,0x61,0x64,0x67,0x65,0x74,0x62,0x72,0x69,0x64,0x67,0x65,0x22,0x2c,0x74,
0x69,0x74,0x6c,0x65,0x3a,0x22,0x22,0x2c,0x73,0x75,0x62,0x6a,0x65,0x63,0x74,0x3a,0x22,0x46,0xf6,0x6e,
0x20,0x4b,0xfc,0x72,0x20,0x42,0xe4,0x72,0x22,0x2c,0x62,0x6f,0x64,0x79,0x3a,0x22,0x46,0xf6,0x6e,0x20,
0x4b,0xfc,0x72,0x20,0x42,0xe4,0x72,0x22,0x2c,0x73,0x65,0x6e,0x64,0x65,0x72,0x3a,0x22,0x46,0xf6,0x6e,
0x20,0x4b,0xfc,0x72,0x20,0x42,0xe4,0x72,0x22,0x2c,0x74,0x65,0x6c,0x3a,0x22,0x46,0xf6,0x6e,0x20,0x4b,
0xfc,0x72,0x20,0x42,0xe4,0x72,0x22,0x7d,0x29,0x0a])

That should send over the exact bytes that Gadgetbridge sent to your watch. Does it happen?

So... as far as I can tell this happens when the messages get saved to Storage (so it's a Bangle.js firmware issue). If you have a fast-load clock face (or you're on the messages app) then the messages are never saved and are actually ok.

@kosi2801
Copy link
Author

Ok, I'm not very experienced with the WebIDE yet but thanks for the hint with having the Messages app open when a notification arrives (can also do via Debug-menu in App or sending a mail to myself), this has led to some interesting results. Following screenshots and descriptions of their cause and content:

This screen shows 3 messages. The topmost one was received while having the Messages app open, the middle one was received just before opening the Messages app and the bottom one is an older one from prior tests. This one has looked differently previously but seems to have been mangled over time.
edited_IMG_20230615_133418

This is the screen that shows up when I'm still inside the Messages app and a new mail with umlauts arrives at that moment.
edited_edited_IMG_20230615_142146

Then I leave the app, go to the watchface, let the watch lock itself and turn the backlight off. After a minute I activate it again and open the messages app again and it looks like this:
edited_IMG_20230615_142226

With those results I somehow suspect that each time a new message is received, also the older ones get re-written and modified again, messing them up more and more over time. This would also support your suspicion @gfwilliams that it's not the notification itself but rather the process of storing/loading it to/from internal memory.

@gfwilliams
Copy link
Member

Thanks! Yes, that sounds very likely. It seems that the process of reading Unicode and then writing it back is causing problems.

I've finally fixed this, mainly with aa64b17 - but it turns out there were a whole series of issues:

  • Gadgetbridge isn't sending UTF8, but some of those characters can be interpreted as UTF8
  • When writing to JSON, the spec says we have to use unicode escapes even if the chars aren't unicode, so then when reading the JSON file the resulting strings are UTF8
  • Finally wrapString (and join/split) didn't like Unicode strings very much. I'm sure there will be other issues as well.

But, finally, I think it's fixed, at least in this case!

There are more issues I think where we add UTF8 string together, but I'll fix those next week

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants