search

Helium314 / HeliBoard

Customizable and privacy-conscious open-source keyboard
Apache License 2.0
2.45k stars 97 forks source link

Backspace does not work correctly in some applications #497

Open 2ip1 opened 9 months ago

2ip1 commented 9 months ago

Describe the bug

In some apps or websites the backspace key stops working or does not work for certain actions. e.g. in Logseq an empty line cannot be deleted. Deleting content works as expected.

This issue was also reported in Openboard: https://github.com/openboard-team/openboard/issues/729 @bgvaughan reported that there are also issues in HedgeDoc (which I was able to reproduce with HeliBoard) @enos-ape reported that the wrong JavaScript keycode is being sent

To Reproduce

  1. Download Logseq
  2. Open the app
  3. Write a line, hit enter, and try deleting the new block with backspace
  4. Lines without content cannot be deleted

Expected behavior

If i press backspace in an empty line, the line should be removed. This works in other keyboards (e.g. swiftkey)

Screenshots

App version

HeliBoard 1.0-alpha1

Device (please complete the following information):

pudup commented 9 months ago

Can confirm. And here I thought it was a logseq issue.

codesalatdev commented 7 months ago

I can also confirm this issue, I am an active Logseq and Hedgedoc user (the latter is used with Firefox). However, the keycode 229 is the same when using FlorisBoard, with which I am perfectly able to delete a block in logseq.

Sudrien commented 7 months ago

Seeing similar behavior in one ui 5.1.1 + tumblr 33.9.0.110 + 1.0 release Backspace will not proceed when it hits a newline while writing a post.

The dumb question: is it a carriage return + linefeed thing?

codokie commented 6 months ago

making the following change : https://github.com/codokie/HeliBoard/commit/ee10fe8e021d60a734b3927cffcd3c944c722fb2 seems to solve the issue , but i am not sure yet if there might be any side effects to sending a keycode DEL when the codepoint of the character before the cursor is undefined

Helium314 commented 6 months ago

I would very much expect that this code exists for a reason (given the text). Further this is a change I would expect to cause issues other apps (at least the "broken ones" whoever was writing that comment was referring to).

Also consider that sending key events is discouraged.

(Ideally whatever happens would be reproduced by some unit test, this helps fixing stuff while avoiding regressions. But this stuff is rather complicated, and I gave up trying to create a proper simulation of what is happening in a "normal" app.)

codokie commented 6 months ago

Do you think that removing the call to deleteTextBeforeCursor() is problematic? I know it is not a good practice to use sendKeyEvent(), but it seems like it is done in at least 2 other places inside the handleBackspaceEvent() function.

As you can see here, FlorisBoard sends a KeyEvent.DEL in situations like this.

There is no reason to insist there is no text before the cursor when the app is seemingly "broken". Whoever wrote that comment is mistaken about the "Nothing to delete before the cursor" part.

Helium314 commented 6 months ago

I finally had a look at Logseq (btw I think this is one of the most horribly slow apps I ever used).

There is indeed nothing to delete before the cursor, because each line looks like separate text field. I assume the way of expecting a delete key press to delete nothing, but not the preferable (see documentation) InputConnection.deleteSurroundingText, is because it's simpler to handle (using a KeyListener). And maybe because the dev happened to use a keyboard that sends a delete keypress and assumed every keyboard does that. Or maybe it's some sort of web-based app is actually using JS (because multiplatform), which could explaing both the bad interaction with native Android methods and bad performance.

It looks like expecting a delete press is a case where "everyone is doing it wrong", so it still ends up as somehow right. And devs of other keyboards seem to have given up on expecting apps to behave "nicely", which give rise to issues like this, and the issue where apps explicitly want no suggestions in fields but users want it (leading to keyboards just ignoring the flag).

Anyway, my main fear with switching to the apparently new norm is that apps that expect the other workaround now will have issues when pressing delete in an empty field... unfortunately there is no readily available info on this.

codesalatdev commented 6 months ago

Or maybe it's some sort of web-based app is actually using JS

It is. Logseq can be used in a web browser and one can reproduce this issue on https://demo.logseq.com

Hedgedoc behaves the same and so does Microsoft's Monaco Editor https://microsoft.github.io/monaco-editor/playground.html which makes me feel like it'd be easier to work around than to change whatever all of them are using to process input.

Edit: The Quill Editor (https://quilljs.com/playground/snow) just multiplies text before the cursor when trying to delete it, which is also interesting behavior.

Gaurav-049 commented 1 month ago

I also confirm, I am also facing this issue . And its not just limited to logseq , even in google keep, backspacing at an empty checkbox should delete the checkbox and move the cursor to the above check box but it doesn't happen.

OS: Android 14. Device: Samsung F14 5g.

With other keyboards like samsung keyboard, this issue is not there.

This issue makes heliboard completely unusable for me. Hope this gets fixed soon.