Pasted text is deleted when backspace is pressed

[Uranusek]

Describe the bug
If you paste text with a space at the end and then want to remove that space, all text will be deleted. The same thing happens if there is a dot, comma and probably other symbols at the end of the text.

This happens when you paste text using the clipboard suggestions or select from the clipboard view, but not when you hold down the clipboard key to paste.

To Reproduce

1. Type something and add a space at the end
2. Copy this text
3. Paste it using the clipboard suggestions or selecting it from the clipboard view
4. Tap backspace
5. See that all pasted text has been deleted

Expected behavior
The text is not removed, only the space at the end.

Screenshots

See videos

Clipboard suggestions

screen-20240729-172751_1.mp4

Clipboard view

screen-20240729-180050_1.mp4

App version
2.2, but probably also in older versions

Device:

• Model: Motorola
• OS: Android 11

[Symbiomatrix]

Paste is a tad overly sensitive, if you delete right after pasting (and I believe even moving the cursor around didn't change that) then it'll act like undo and delete the whole paste block. I guess it's useful if you've pasted in the wrong place. A relatively easy workaround is to add a single space then delete twice (though admittedly it takes a bit of training).
At least that's how it was for me in the beginning; For some reason this behaviour stopped for me by now (as you'd like) and backspace always acts like backspace. I'm not sure how that happened as I don't recall changing any setting for this explicitly so I can't point it out to you, but maybe someone more familiar with the keyboard knows.

What about you, @Uranusek ? I assume you've been using the keyboard for a week or so, has this gone away by now?

[BlackyHawky]

I used to have exactly the same bug, but it doesn't show up anymore either.
The only thing I've done since becoming aware of the bug is to restart my phone (but I can't see how that's related).
Very strange.

[Uranusek]

I restarted the phone and even reinstalled the keyboard, but the problem persists. I have been using this keyboard for a very long time and have not seen this bug. Maybe it was there, but I didn't notice it. I only noticed it after adding the "clipboard suggestion" feature. Maybe that's the reason? 🤔 I will check the version before adding this feature.

[Symbiomatrix]

@Uranusek For what it's worth, I've been using it for about a day, 2.2. I did mess with almost all the settings though, customising layouts and removing the default popups mostly, some autocorrect stuff. I have "suggest clipboard content" on.
I've just made a couple major discoveries: See, I've added copy & paste to my layouts as keys, and removed the clipboard from the toolbar menu.

• When I paste regularly, delete never acts up (as you've pointed out in the issue, I see that now).
• When I paste through clipboard, some texts cause the undo and some do not; the difference appears to be whether the copied text ends with an a-z letter: label: will be deleted entirely, label deletes regularly, label with space deletes entirely. Try it out and see if it's the same for you.

Looks to me like after the clipboard paste happens, it tries to apply the "autocorrect suggestions" feature, but if there's no word then it has the whole text invisibly selected or something.

[Uranusek]

Try it out and see if it's the same for you.

Yep, it's the same for me. Text ending with a letter will not be deleted. But if there is a symbol or a space at the end, then everything is deleted. I wrote about this when creating the issue, but I didn't mention that text is not deleted if there is a letter at the end.

Looks to me like after the clipboard paste happens, it tries to apply the "autocorrect suggestions" feature, but if there's no word then it has the whole text invisibly selected or something.

I checked the autocorrect settings and even turned it off, but the bug still persists.
This is very strange, because as we noticed, it does not appear when we paste using the buttons.

[Symbiomatrix]

It actually makes sense, though I'm not sufficiently versed with android app code to tell for sure: I'd think paste is probably implemented as an OS operation and so it should be bug free. Whereas clipboard manager's paste is a feature implemented in this app.

I couldn't exactly find how paste is implemented, but clipboard paste is fairly straightforward, I think:

• app/src/main/java/helium314/keyboard/latin/inputlogic.handleClipboardPaste() simply calls mLatinIME.onTextInput using the clipboard content it retrieves (presumably based on user selection): mLatinIME.onTextInput(clipboardContent)
• app/src/main/java/helium314/keyboard/latin/LatinIME.onTextInput(rawText) does the following:

        final Event event = Event.createSoftwareTextEvent(rawText, KeyCode.MULTIPLE_CODE_POINTS);
        final InputTransaction completeInputTransaction =
                mInputLogic.onTextInput(mSettings.getCurrent(), event,
                        mKeyboardSwitcher.getKeyboardShiftMode(), mHandler);
        updateStateAfterInputTransaction(completeInputTransaction);
        mInputLogic.restartSuggestionsOnWordTouchedByCursor(mSettings.getCurrent(), mKeyboardSwitcher.getCurrentKeyboardScript());
        mKeyboardSwitcher.onEvent(event, getCurrentAutoCapsState(), getCurrentRecapitalizeState());

There's the "restartSuggestionsOnWordTouchedByCursor" for autocorrect, which I'd guess does nothing if there's no word in the position as is the case here. And updateStateAfterInputTransaction probably treats the text as a unit. This might be a standard text insert function, so maybe need to find out what restartsuggestions does to the cursor regularly, and add that as a fallback to paste.

Edit: Oof, right off the bat in app/src/main/java/helium314/keyboard/latin/inputlogic.restartsuggestions, spacing and punctuations are disabled as a hack with a note on how it might break things, so I guess we're on the right track:

        // HACK: We may want to special-case some apps that exhibit bad behavior in case of
        // recorrection. This is a temporary, stopgap measure that will be removed later.
        // TODO: remove this.
        if (!settingsValues.mSpacingAndPunctuations.mCurrentLanguageHasSpaces
                // If no suggestions are requested, don't try restarting suggestions.
                || !settingsValues.needsToLookupSuggestions()
                // If we are currently in a batch input, we must not resume suggestions, or the result
                // of the batch input will replace the new composition. This may happen in the corner case
                // that the app moves the cursor on its own accord during a batch input.
                || mInputLogicHandler.isInBatchInput()
                // If the cursor is not touching a word, or if there is a selection, return right away.
                || mConnection.hasSelection()
                // If we don't know the cursor location, return.
                || mConnection.getExpectedSelectionStart() < 0) {
            mSuggestionStripViewAccessor.setNeutralSuggestionStrip();
            return;
        }

And here, a couple lines down, I think it's finishComposingText which clears this "invisible selection" I mentioned:

            // "unselect" the previous text
            mConnection.finishComposingText();

That one's in app/src/main/java/helium314/keyboard/latin . That's about as deep as I can go, no idea whether it'd be right to just throw that in the paste code, I sense not. I'm quite surprised my hunch even went this far.

[Uranusek]

I don't know much about code, so I don't understand what you wrote, sorry 😅

@codokie was working on the clipboard, so maybe he will know what causes this bug.

[codokie]

This sounds like a quirk of onTextInput(), I can't debug it currently but as a workaround for the clipboard suggestions you can replace the call to onTextInput() with a call to pickSuggestionManually():

latinIME.pickSuggestionManually(
                SuggestedWordInfo(
                    content.toString(), "",
                    SuggestedWordInfo.MAX_SCORE,
                    SuggestedWordInfo.KIND_HARDCODED,
                    Dictionary.DICTIONARY_HARDCODED,
                    SuggestedWordInfo.NOT_AN_INDEX,
                    SuggestedWordInfo.NOT_A_CONFIDENCE
                ))

I think this should solve it although it would have to be tested.

[Staubsaugerbeutel]

Isn't this a feature? I'd rather be able to delete a huge accidentally pasted text than accidentally deleting it a few times until i get used to the feature? (OK I can use undo too hmm)
Only seems to happen after a certain length (doesn't happen to a single word)

[Uranusek]

Isn't this a feature?

To me it looks like a bug, because it doesn't happen if there is a letter at the end of the text.

I'd rather be able to delete a huge accidentally pasted text

Maybe a toggle could be added in the settings if you (and someone else) prefer the current behavior.

[Uranusek]

@codokie I checked and it works for clipboard suggestions. Thanks!

Now the bug only occurs if I paste an entry from the clipboard view. Do you have any idea how to fix it? I can only test.

[herrbrixter]

When I paste something from the clipboard layout, the delete button deletes everything. This happens in all cases regardless if the pasted text ends with a symbol or a character.

[codokie]

The problem seems to be with this if block.
It's meant for deleting emojis and other special characters which consist of multiple code points, but the deletion should be adjusted so that only the last (visible) character of the entered text will be deleted.
About half of my PRs have been ignored by the busy repo owner, so I don't know whether I should spend more time to write a fix..

[Uranusek]

I see. I hope you decide to create a PR and it will be merged quickly. This bug is really annoying.

Maybe also for this feature? #993 I checked and it works.

For now, I will use the version in which I implemented your suggestions. Thanks again.

[Helium314]

The problem seems to be with this if block. It's meant for deleting emojis and other special characters which consist of multiple code points, but the deletion should be adjusted so that only the last (visible) character of the entered text will be deleted. About half of my PRs have been ignored by the busy repo owner, so I don't know whether I should spend more time to write a fix..

I wanted to first reply here after coming back from my break because this post is what made me decide I just need a complete break from GitHub. It's not the actual reason, but very much connected.

Initially, for about a month I dedicated almost my entire spare time to your PRs, and after that still spent a considerable part of that spare time on your PRs alone. A big chunk of the time I needed for your PRs was because reviewing large PRs takes disproportionately more time than small PRs. There are more things that make review faster and easier, which are in my PR guidelines. I had hoped that by reminding you how I want the PRs done to save time, you would improve on that, so that at some point reviewing would actually be faster than if I had written the code myself. But you showed no interest in improvement on following the guidelines, and instead complained about "being lectured". You say you mash together PRs so you would save a little time on not having merge conflicts, and try to reframe insufficiently describe multiple PRs mashed into one as "overhaul". It seems you don't care how much of my time you waste, and apparently you don't want to spend a little extra time on practicable cooperation.

You actually managed to make be go from being genuinely happy about new PRs to "oh no, not another one" in about 6 weeks. And it seems this damage is lasting.
I really would have liked to have you as main contributor, as you seem to have very good understanding of this app. But when I take additional hours to properly dissect a many-in-one PR of yours, and then you say you want to save time on merge conflicts, it feels somewhere between a bad joke and an insult. It would have been better if I just closed your PRs when it became clear that there is no improvement coming, so you wouldn't waste time on writing another one, and I wouldn't have to do any review. But I probably was too desperate towards getting another contributor, which is absolutely necessary for this app on the long run.

Anyway, for my own sanity I decided I will not review any of your PRs any more. If someone else takes over and properly reshapes your contributions so they follow the guidelines, I'm willing to review (and hopefully merge) those.

Btw 9 of 31 PRs still open is not "about half".

---

Otherwise, I'll slowly have a look at what has been going on in tha past 2 months and finish the next release, but will remain less active than previously.
I've never been interested in managing the issue / discussion part of a repository, it's more of a "necessary side effect". In principle I'm ok with taht, but it keeps taking more and more time. And already a while ago, the tons of non-development activity was too much for me, which resulted in reduced interest in my work here...

[codokie]

@Helium314 wow, I never meant to make you this upset, but that is kind of off-topic here, so maybe it should be marked as such?

Let me start by saying I think we both have lost a fair share of interest with this project, otherwise we would not have complained about our time being wasted on reviewing the code.

That said I do appreciate the time you had put into reviewing my work — I've learned quite a bit thanks to your remarks. I might be stubborn at times, but you have to understand that my time is just as important as yours.

To split a PR into smaller ones is time-consuming, and for a git newbie like me it can be quite daunting to handle the merge conflicts. It may not even make sense to do so if the proposed changes are correlated or when not many lines of code have been modified.

For many days, I had worked for hours without pay trying to improve the keyboard, but on multiple occasions I was strongly discouraged by the strict PR guidelines and lack of enthusiasm to work in tandem. So excuse me but I still don't think I'm the one solely responsible for the fiascos of #613 and #828.

It would be a shame if long-awaited enhancements such as #838 and #722 (both of which haven't been reviewed yet) were to be discarded.. but ultimately I respect your decision to dismiss my efforts, just don't expect future contributors to like this kind of treatment.

Best of luck to you in your future endeavors.