Franz: Back-space character is added sometimes automatically in Slack

Created on 6 Dec 2017  Â·  13Comments  Â·  Source: meetfranz/franz

â– Environment
 Franz : 5.0.0 beta.14
 OS : Mac(Darwin Kernel Version 15.3.0)

â– scenario
 1. Add Slack app to Franz.
 2. Add some characters in the Slack.
 3. Sometimes, it seems to mingle strange character.
 4. Copy it and paste to sublime-text3, then it look "BS" character.

How can I solve this problem?
Thenks your help.

more information required

Most helpful comment

I confirmed below :

  • Spellcheck function is not the cause.
  • Character encoding of GitHub recipe is utf-8, so it's no problem too.

I found the method for reproducing bug by referring @KaiShoya 's comment.
When IME mode is enabled, you can delete the characters in the middle of converting by hitting delete or backspace key.
And It will also cancel the IME mode to hit them when the input buffer has only 1 character
but this operation will cause the bug with Franz.

ime_test

All 13 comments

I add screen photo.
↓ is in Slack.
image

I copied ↑ , and pasted to Sublime-text3.
image

@koma-private is this something you can reproduce?

Although I've not experienced this issue as for daily use of Slack, I have similar problems regarding character encoding when using GitHub via Franz.

Env :

Problem :
An Unicode special character � = "REPLACEMENT CHARACTER" (U+FFFD / 0xEFBFBD) is occasionally inserted to Japanese messages

github_error

@koma-nain

Does this problem occur only when your using Slack? What about the other recipes?

Yes, it occurs only when I using Slack.

What kind of IME do you use? (System default?)

I use Google Japanese Input ( ↓ is screen-photo when I click "About Google Japanese Input" on Mac Book)
image

It seems BS characters will be inserted in your environment only when your starting new line. Isn’t it?

Hmm...
It seems this problem occurs in that situation, but I don't know it is always.

Best regards.

I did several tests.

  1. Google Japanese Input is not cause of this issue. I encountered same problem even when I use Mac OS's default IME (Kotoeri)
  2. Adding a property webPreferences="defaultEncoding=utf-8" to ServiceWebview doesn't solve this too.
  3. I disabled spellcheck function of Franz. I'm not sure this is the cause, but now I continue input testing without spellcheck.

@st22 Do you enable the spellcheck function of Franz?

Sorry for my poor English.
I have the same problem.

Deleting characters before conversion completes will cause this problem.
It didn't matter whether the spell check function was enabled/disabled.

Hi, @koma-private

Do you enable the spellcheck function of Franz?

I don't use spellcheck function of Franz.
So, as @KaiShoya said, it seems that spellcheck function of Franz is not cause.

Best regards.

I think the github recipe problem is not necessarily the same issue as the original one. Let me explain, i'll take github as primary example.

The replacement character is shown every time the utf-8 "parser" encounters a character that can not be shown in utf-8, as the byte-code is not utf-8. FYI, utf-8 has always the same starting bits in a two-byte sequence.
So I guess the editing field in the github recipe is propably in a not-utf-8 setting.

The other problem is about an extra BS character. Although it could also be about mixing character sets, I'm not sure it is.
@koma-private or @st22 could you recreate a text including this bug and copy this directly into a comment field? I'm hoping to be able to reproduce the issue using the text you generate. Perhaps the combination of the "round-dot" character and the EOL character(s) might be the clue we're looking for.

I confirmed below :

  • Spellcheck function is not the cause.
  • Character encoding of GitHub recipe is utf-8, so it's no problem too.

I found the method for reproducing bug by referring @KaiShoya 's comment.
When IME mode is enabled, you can delete the characters in the middle of converting by hitting delete or backspace key.
And It will also cancel the IME mode to hit them when the input buffer has only 1 character
but this operation will cause the bug with Franz.

ime_test

Although I cannot see these special characters in Slack, it produce an error to send a "fake" blank message made by the same key operation as explained above.

2017-12-16 19 58 08

UPDATE : This problem is already issued in electron.
https://github.com/electron/electron/issues/9173

closing this for now as this is a known issue in electron ... feel free to reopen the issue with any questions or comments!

Electron v2.0 has been fixed the upstream issue, but Franz still uses Electron v1.8.4. When will Franz move to use v2.0.x ...?

https://github.com/electron/electron/issues/9173

@h6ah4i
Thank you for info. I checked the IME issue by using my private build of Franz.
It seems building Franz with Electron 2.0.3 will solve this problem.

test_electron203

My past comment:

When IME mode is enabled, you can delete the characters in the middle of converting by hitting delete or backspace key.
And It will also cancel the IME mode to hit them when the input buffer has only 1 character
but this operation will cause the bug with Franz.

@haraldox
Could you re-open this issue? because I'm not authorized to do.

Was this page helpful?
0 / 5 - 0 ratings

Related issues

sach160 picture sach160  Â·  4Comments

Guredaniel picture Guredaniel  Â·  3Comments

dbfin picture dbfin  Â·  4Comments

AGonLen picture AGonLen  Â·  4Comments

thmsnhl picture thmsnhl  Â·  4Comments