Only in Copy/Move Dialog: Some Software Keyboards Misbehave In Search Input

[GfEW]

Checklist

• [X] I can reproduce the bug with the latest version given here.
• [X] I made sure that there are no existing issues - open or closed - to which I could contribute my information.
• [X] I made sure that there are no existing discussions - open or closed - to which I could contribute my information.
• [X] I have read the FAQs inside the app (Menu -> About -> FAQs) and my problem isn't listed.
• [X] I have taken the time to fill in all the required details. I understand that the bug report will be dismissed otherwise.
• [X] This issue contains only one bug.
• [X] I have read and understood the contribution guidelines.

Affected app version

1.1.1

Affected Android/Custom ROM version

Android 9 to 11

Affected device model

diverse

How did you install the app?

F-Droid / IzzyOnDroid

Steps to reproduce the bug

1. In Fossify Gallery, mark any items (media files or folders) in any folder or flat view.
2. In the three dots menu at the upper right, tap at "Copy to" or "Move to".
3. In the dialog to select a destination, tap at the search line and type some characters
4. Try to delete the last typed character or to move around pressing left arrow, right arrow, home or end keys.

Expected behavior

Pressing backspace should delete the character before the text cursor (if any), and pressing the cursor keys should move the text cursor around (within the typed characters).

Actual behavior

Cursor keys don't move the text cursor, and backspace may or may not delete the preceding character (depending on the particular keyboard app).

Screenshots/Screen recordings

No response

Additional information

• This bug only applies to the search input line in the Copy/Move destination chooser. Search input lines in Fossify Gallery's main screen (folders or flat) or in any folder view are unaffected.
• Affected software keyboards include Hacker's keyboard and Unexpected keyboard. Should I find more, I will add them to this list.
• According to a comment to #128, Gboard, SwiftKey and AnySoftKeyboard are partially affected (backspace works, cursor keys don't).

[Aga-C]

I also tested on Simple Keyboard (soon to be Fossify Keyboard), and backspace works fine here too. It seems to be a problem with Hacker's keyboard and Unexpected keyboard, maybe their backspace implementation isn't standard and somehow relates to usage of arrows. Since backspace works on most popular keyboards and the problem is only with arrows, and they aren't that commonly used on software keyboards (they are often hidden), I tagged is as a niche problem. However, I can confirm the bug exists.

[GfEW]

Thanks for testing, and elaborating on the label, I can understand the decision.

Since search input in the Copy/Move destination chooser seems to behave in a few quirky ways that all other text input lines (including searches) in Fossify Gallery don't, I assume there's a different, single-use chunk of code at work - despite the very similar (if not identical) task.

Is there any reason the working generic search/filter code isn't reused there? Maybe those little "Only in Copy/Move destination chooser" issues would vanish all at once.

[Patriclis]

I do not have a third party software keyboard installed - using the default "Samsung Keyboard" that comes with my device - and am also experiencing this issue in the gallery app as well as the file manager app.

I've only tried with the backspace key, my arrows are hidden.

Gallery Version

1.1.1

File Manager Version

1.0.0

Device

Samsung Galaxy S20 FE

Keyboard

Samsung Keyboard Version 5.6.10.40

Additional Details

All other details are the same as the original ticket.

[mnalis]

I can also reproduce the problem with Fossify Gallery 1.2.1 (from F-droid) on Samsung Galaxy S23+ (Android 14, degooglified) both with with https://f-droid.org/en/packages/rkr.simplekeyboard.inputmethod/ and with stock Samsung keyboard.

The problem affects the backspace (I have no arrow keys to try), and not regular letters; and as mentioned it ONLY occurs in Copy/Move destination chooser. E.g. when renaming the file from Gallery backspace works just fine.

Here is video:

https://github.com/user-attachments/assets/7164e25b-14d3-4b40-ae3b-8f73ce680922

I also seem to recall it used to work just fine a year or so ago (but cannot guarantee it; it could've been other phone).

No other app I have ever used has this backspace problem (either in Simple Keyboard nor Samsung stock keyboard).

[mnalis]

I've also tested same Fossify Gallery 1.2.1 (from F-droid, and also the release from github) on Xiaomi Redmi Note 6 Pro running LineageOS 18.1-20221024-NIGHTLY-twolip (Android 11). Results:

• Same problem with backspace in Copy/Move (but not Rename) dialog with Simple Keyboard 5.25
• in stock LineageOS AOSP keyboard, backspace works in both situations
• in Fossify Keyboard 1.1.1, backspace works in both situations

[rkkr]

This applies not just to some keyboard application but also to physical (BT) keyboards. None of the physical keyboard keys work so you can't even type in those fields. Seems to be cause by https://developer.android.com/reference/android/view/KeyEvent not being handled by application.

Can also reproduce in emulator by clicking a PC keyboard.

[GfEW]

@rkkr

This applies not just to some keyboard application but also to physical (BT) keyboards. None of the physical keyboard keys work so you can't even type in those fields.

That's actually how I discovered this bug along the way, see #128 .

In my (limited) understanding, every hardware keyboard uses a software keyboard to actually produce keyboard input to other apps. If there are multiple keyboard apps available on your device, you can choose in android settings ("physical keyboard") which one to assign to the hardware keyboard.

However, whilst #128 also shows all symptoms of this #145 , its main symptom is more severe, which suggest it does make a difference whether or not a software keyboard is operated on-screen or via connected hardware keyboard.

[rkkr]

every hardware keyboard uses a software keyboard to actually produce keyboard input

This statement is not correct. There is even a setting "Use on-screen keyboard" that disables the software keyboard when a BT one is connected.

[GfEW]

@rkkr

every hardware keyboard uses a software keyboard to actually produce keyboard input

This statement is not correct. There is even a setting "Use on-screen keyboard" that disables the software keyboard when a BT one is connected.

Misunderstood doesn't imply incorrect. (That's not meant to say the statement is correct, either - I simply don't know the inner workings of input handling on android well enough.)

On my devices, that option is active everywhere, causing software keyboards to show up only when no hardware keyboard is connected. In my experience however, the soft keyboard then continues to do its job, regardless of being hidden or visible: the connected hard keyboard generally behaves according to the characteristics and settings of the soft keyboard associated with physical keyboards, as if you tapped the corresponding on-screen keys.

That's what makes the difference between #128 and #145 so puzzling (to me, FWIW).

[rkkr]

That's what makes the difference between #128 and #145 so puzzling (to me, FWIW).

Do you mean the what is the difference between "some software keyboard some actions/buttons not working" and "physical keyboards not working"? The answer to that is "none". As I noted before physical keyboards send https://developer.android.com/reference/android/view/KeyEvent, some software keyboards also use these low-level events to move the cursor, delete, or even add letters.

The difference between working and not working software keyboards is the same KeyEvent. As an IME developer you can either send low-level events via KeyEvent or use function like commitText, setSelection, deleteSurroundingText in https://developer.android.com/reference/android/view/inputmethod/InputConnection which interact with the input field at a "software level".

The gotcha is that just like some apps don't properly handle KeyEvent, some apps don't properly handle the "software events". It is also much easier to implement some functions imitating physical keyboard clicks and letting the OS handle all the validation logic.