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

Fix issue where soft keyboard would not show in some cases #2114

Conversation

agnostic-apollo
Copy link
Member

  1. If soft-keyboard-toggle-behaviour=enable/disable was set, then pressing keyboard toggle wouldn't show the keyboard after switching back from another app if keyboard was previously disabled by user.
  2. If switching back from another app, like when opening url with context menu "Select URL" long press and returning to termux with back button, then soft keyboard wouldn't automatically open like it does on app startup.

Fixes #2111, Fixes #2112

@trygveaa Here it is, kindly test. Thanks.

Copy link
Contributor

@trygveaa trygveaa left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Great, now the keyboard opens after returning from a URL or locked screen. However, is there a reason that the keyboard should open even if it was hidden before? I think it would be better if the keyboard remained in the same state as it was previously when you return, so that if you hide the keyboard and change to another app, it's still hidden when you switch back to Termux.

Of course, if you use the disable toggle, it will be closed when you come back to Termux, but if it behaved the way described above, I would prefer using the toggle as show/hide instead of enable/disable.

There is also still one issue remaining with the enable/disable toggle. If you press back to hide the keyboard, you still have to press the toggle twice to open the keyboard.

Logger.logVerbose(LOG_TAG, "Enabling soft keyboard on toggle");
mActivity.getPreferences().setSoftKeyboardEnabled(true);
KeyboardUtils.clearDisableSoftKeyboardFlags(mActivity);
KeyboardUtils.showSoftKeyboard(mActivity, mActivity.getTerminalView());
mActivity.getTerminalView().postDelayed(getShowSoftKeyboardRunnable(), 300);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is this delay necessary? Just requesting focus makes it works for me. I see no difference in behavior with or without the delay, except that toggling the keyboard now has a delay.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, as mentioned in the comment above it. It requires a delay after steps from #2112 on my device. It works with 100ms too, but may not work for other slower devices. I have no way to know the correct one unless multiple testers come and say it works for them, so better to set a looser delay, since releases are slow. And at least 300ms may be required anyways. The setSoftKeyboardVisibility() called by onFocusChange() has it at 500ms.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Okay, that's a bit surprising. I see that the delay is required when auto opening the keyboard after returning to Termux (the delay later down in this file), but here there would be some time between returning to Termux and pressing the button anyways (I don't think one would be able to press the button within a couple of hundred ms after returning to the app). I'm not doubting what you're saying, just wanted to make sure it's necessary in both cases.

The problem is not so much that there is a delay after returning to the app though, but that this also causes a delay when you haven't left the app. E.g. just press the toggle to disable and then press again to enable. This delay is not present in master, so I would assume it's not necessary in this case? Would it be possible to differentiate between these cases, so the delay is only used when you return to Termux, and not when you toggle the keyboard when Termux is active all the time?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

, but here there would be some time between returning to Termux and pressing the button anyways

I was wondering about that too, I tried multiple configurations, but delays seems necessary.

Would it be possible to differentiate between these cases

Yeah, a boolean can be added, just like mShowSoftKeyboardIgnoreOnce, delays seems to be required only after app changes.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah, a boolean can be added, just like mShowSoftKeyboardIgnoreOnce, delays seems to be required only after app changes.

Great, or alternatively we could call it both immediately and with a delay? That would fix the issue when toggling when Termux is active, and it wouldn't introduce a delay after app switch for devices that don't need it. Or would that be too hacky?

Copy link
Member Author

@agnostic-apollo agnostic-apollo Jun 6, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I have some delay

Delay in what? Enabling keyboard with toggle if it was previously disabled?. onCreate will always have its own delay to set up stuff, so showing keyboard automatically (which also has 300ms delay) or with toggle will have "some" delay anyways.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Delay between pressing the keyboard toggle and the keyboard appearing. That is after returning to the app when the keyboard is disabled, so not when it appears automatically.

These are the two cases:

With destroy:

  1. Press the toggle to disable the keyboard.
  2. Press back to leave (but not exit) the app.
  3. Return to the app by pressing it in recent apps or the launcher.
  4. Press the keyboard toggle to open the keyboard again.
  5. The keyboard will appear.

Here there is some delay between 4. and 5. even if I remove the delay from the code.

Without destroy:

  1. Press the toggle to disable the keyboard.
  2. Press home to go to the home screen.
  3. Return to the app by pressing it in recent apps or the launcher.
  4. Press the keyboard toggle to open the keyboard again.
  5. The keyboard will appear.

Here the only delay between 4. and 5. is the delay specified in the code. If I remove that delay the keyboard opens immediately.

I'm asking if the delay specified in the code is necessary in both cases for the keyboard to appear on your device, or if it is sufficient to have it in the first case.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It seems its only required if onCreate is called. I have made the changes, but if its also required even when onResume is called without onCreate on startup on some device, then we all know who will be coming after.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Perfect, thanks! Working great for me now.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Great, welcome. Merging.

@agnostic-apollo
Copy link
Member Author

agnostic-apollo commented Jun 6, 2021

However, is there a reason that the keyboard should open even if it was hidden before? I think it would be better if the keyboard remained in the same state as it was previously when you return, so that if you hide the keyboard and change to another app, it's still hidden when you switch back to Termux.

There is no reliable way for termux to know whether the soft keyboard is open or closed, so I can't save the state before leaving termux. It only works with enable/disable because I'm using the disable flags as a hack.

There is also still one issue remaining with the enable/disable toggle. If you press back to hide the keyboard, you still have to press the toggle twice to open the keyboard.

That's expected behaviour and won't change. There is a difference between hide and disable. When you hide, you should tap the terminal view for it to show. When you disable, you should press keyboard toggle to show it again. When you press the keyboard toggle in enable/disable mode, as mentioned above, termux doesn't know if keyboard is hidden or shown, it only sets/clears disable flags. It works on twice press, because on first press, it sets the disable flags, second time clears the flags and shows the keyboard. Check logcat | grep -i keyboard for transitions with verbose log level. Use show/hide instead for your behaviour.

@trygveaa
Copy link
Contributor

trygveaa commented Jun 6, 2021

There is no reliable way for termux to know whether the soft keyboard is open or closed, so I can't save the state before leaving termux. It only works with enable/disable because I'm using the disable flags as a hack.

Oh, okay, too bad.

That's expected behaviour and won't change. There is a difference between hide and disable. When you hide, you should tap the terminal view for it to show. When you disable, you should press keyboard toggle to show it again. When you press the keyboard toggle in enable/disable mode, as mentioned above, termux doesn't know if keyboard is hidden or shown, it only sets/clears disable flags. It works on twice press, because on first press, it sets the disable flags, second time clears the flags and shows the keyboard. Check logcat | grep -i keyboard for transitions with verbose log level. Use show/hide instead of your behaviour.

I think it would be more useful/practical if the toggle button always shows the keyboard when it's closed, so you don't have to know if it's disabled or just hidden. But the main reason I want this behavior is that I'm working on being able to open URLs by pressing on them directly, and I was thinking of making the tap action configurable so I don't accidentally open the keyboard if I miss a URL. But okay, if Termux can't know if the keyboard is open or not, I see that it wouldn't be possible.

Did you see my comment about the delay that doesn't seem to be necessary?

@agnostic-apollo
Copy link
Member Author

But the main reason I want this behavior is that I'm working on being able to open URLs by pressing on them directly, and I was thinking of making the tap action configurable so I don't accidentally open the keyboard if I miss a URL.

I guess for that case, as you suggested, the back key can disable the keyboard as well if a termux.properties is true. Maybe that works.

But okay, if Termux can't know if the keyboard is open or not, I see that it wouldn't be possible.

Yeah, but if someone can come up with a hack that works for everybody, then that can be included.

Did you see my comment about the delay that doesn't seem to be necessary?

Already replied to it.

@trygveaa
Copy link
Contributor

trygveaa commented Jun 6, 2021

I guess for that case, as you suggested, the back key can disable the keyboard as well if a termux.properties is true. Maybe that works.

Alright, maybe I'll add that when I make a PR for the click on URL functionality then.

Yeah, but if someone can come up with a hack that works for everybody, then that can be included.

Fingers crossed, though from what you and the others have written in the issue you linked, it doesn't seem easy.

Already replied to it.

Sorry, I didn't see it. I think GitHub showed the one I replied to automatically, but not the other until I refreshed the page. Or I was just blind.

@agnostic-apollo agnostic-apollo force-pushed the fix-soft-keyboard-not-showing-in-some-case branch from 5ad24c4 to 54513e3 Compare June 6, 2021 13:45
@agnostic-apollo
Copy link
Member Author

Alright, maybe I'll add that when I make a PR for the click on URL functionality then.

Cool

Fingers crossed, though from what you and the others have written in the issue you linked, it doesn't seem easy.

Probably not or at least not on all devices.

Sorry, I didn't see it. I think GitHub showed the one I replied to automatically, but not the other until I refreshed the page. Or I was just blind.

Yeah, comments are not always refreshed. Sub comments probably don't either.

But if you do find out that you are actually blind, please let us know. We require our testers to not be blind to test UI changes. Thanks ;)

@RalfWerner
Copy link

The two KB choices in Termux Settings are set to other values ​​regardless of the selected one with each KB action. So they are not needed because they do not do anything or switch permanently to other values.

The double KB action is always repeatable with properties: *on-startup=true, *behaiour=enable/disable, switch KB on, press Start-Menu Key (or sleep mode) and open termux-app again.
With the explanations above, I understood that this can not be prevented.

1. If `soft-keyboard-toggle-behaviour=enable/disable` was set, then pressing keyboard toggle wouldn't show the keyboard after switching back from another app if keyboard was previously disabled by user.
2. If switching back from another app, like when opening url with context menu "Select URL" long press and returning to termux with back button, then soft keyboard wouldn't automatically open like it does on app startup.

Also fixed issue where OnFocusChangeListener wasn't being set up if keyboard had to be hidden or disabled on startup.

Fixes termux#2111, Fixes termux#2112
@agnostic-apollo agnostic-apollo force-pushed the fix-soft-keyboard-not-showing-in-some-case branch from 54513e3 to 1ad038e Compare June 6, 2021 16:34
@agnostic-apollo
Copy link
Member Author

So they are not needed because they do not do anything or switch permanently to other values.

Only 1 Soft Keyboard Enabled toggle value changes outside of Termux Settings and only when soft-keyboard-toggle-behaviour=enable/disable is set, which its supposed to do. It does not change with show/hide. I don't know why you still haven't figured this out yet after all this time.

With the explanations above, I understood that this can not be prevented.

With hide-soft-keyboard-on-startu=true, either double press toggle or touch on terminal view (if keyboard not disabled).

@agnostic-apollo agnostic-apollo merged commit 7225e2b into termux:master Jun 6, 2021
@agnostic-apollo agnostic-apollo deleted the fix-soft-keyboard-not-showing-in-some-case branch June 6, 2021 16:57
@RalfWerner
Copy link

RalfWerner commented Jun 7, 2021

I don't know why you still haven't figured this out yet after all this time.

You're right the *=show/hide Property I had only checked once. It led to "no chance to use OS-KB allways". This is also the case in the currently merded version. I tried to solve the problem with rm .termux/te*, close all apps, reboot of the device and also reinstall the APK. Everything without success. Since I also start the sshd service at the Termux start, the last chance is using the PC and its KB for editing the properties in a ssh Shell.

So far I have tried to understand the OS-KB behavior without source analysis. I can only explain the condition described above by an init problem. Also by commenting:

#hide-soft-keyboard-on-startup=true
hide-soft-keyboard-on-startup=false # doesn't work when Termux Setting is "off"
#soft-keyboard-toggle-behaviour=show/hide
#soft-keyboard-toggle-behaviour=enable/disable

I can not get back the OS-KB. The only chance is to edit with the PC in the Properties *=enable/disable (line 3) But behind *=show/hide or set the first choice in the 7-step setting. Who does not know that, can easily despair or opens Issues.
The second choice I will check on another device (with BT-KB) and inform you again.

Addendum with BT-KB (SM-P610)

With the show/hide setting, the unwanted show of OS-KB can not be prevented and when using BT-KB coupling, OS-KB is no longer possible. With the enable/disable setting and with BT-KB coupling, 3-2 KB taps on KEYBOARD needet also displays the OS-KB. And after decoupling, only one tap is needed.
The second choice in the settings does not change this behavior in both cases. What should be changed with this choice?

@trygveaa Okay, not sure when it shows up unwanted for you ... seems like enable/disable is the only way to prevent this.

unwanted is every show/appear/raise of OS-KB by randomly touch on screen. On SM-P610 with Termux in background or in a big Picture and normal work speed, I get it about 20 times a minute and on Phones 5-10 times.

@agnostic-apollo Unfortunately, with the *=enable/disable setting, X11 OS-KB Toggle partly no longer possible but changed in any case. X11 also supports Split Screen and in Picture and can be used in parallel with VNC (different displays, e.g. :0/:1). If the device is PiP capable, the App Toggle with Tap is possible onto the Picture/Background of the app. VNC works only in background. This allows many combinations, from which I consider here two (P in B). P is a picture with Termux or X11 and B the background with the other app.
I find the behavior extremely confusing. OS-KB is never displayed or always or after various KEYBOARD actions and with B=VNC and two Pictures does nobody understand what happens. Android does not distinguish visually between active pictures/splits, which complicates the understanding of behavior and on non-split-capable devices, the app-toggle takes place via an extra keyX11.

If you want to repeat/understand that on a split-capable device/AVD, is P/B: top/bottom or right/left. VNC is not split-capable.
Do you possibly find a logic and can explain me?

@agnostic-apollo
Copy link
Member Author

@RalfWerner Sorry, I don't understand what you are saying, so can't help. May get someone who can understand your local language and can write readable english to write the comment for you.

If someone else can understand the above comment and can explain, please do.

@RalfWerner
Copy link

Thanks for your response @agnostic-apollo. I assume it's also to my question here. I can understand the two (A: my and B: yours) commits above well when I translate in my local language. So I've prepared a Test with two sentences from above and translate them with google into German -> Spain -> French -> English. before:

A: I find the behavior extremely confusing. OS-KB is never displayed or always or after various KEYBOARD actions
B: I don't understand what you are saying, so can't help. If someone else can understand the above comment and can explain, please do.

after:
A: I find the extremely confusing behavior. OS-KB is never displayed or always or after different keyboard actions
B: I do not understand what you say, so I can not help. If someone else can understand and explain the previous comment, please do it.

The result is still understandable for me, even with the small differences.
If you did not understand the semantics, this can be assigned mistakenly to the language. A picture or movie sometimes says more than 1000 words even if it can be misinterpreted.

Split.mp4

Here you see the behavior of Termux + X11 in Split mode on a real device. The effect is also repeatable to AVD and with other apps as X11. Since I know the effect, can repeat it and avoid, I will not suffice so often. Since you currently have no interest in troubleshooting is Ok and I'm waiting for others to annoy them and open Issues that you understand better.

@agnostic-apollo
Copy link
Member Author

agnostic-apollo commented Jun 13, 2021

Understanding one or two sentences here and there does not mean I understand what you are trying to say overall. And I don't have time to decipher it all.

I find the extremely confusing behavior. OS-KB is never displayed or always or after different keyboard actions

Fill following template (No stories!)

  • Device model:
  • Android Version:
  • Soft Keyboard App:
  • Hardware Keyboard State: connected/not connected
  • Hardware Keyboard Type: usb/bluetooth
  • Android Settings Language And Input Show Soft Keyboard When Hardware Attached: true/false
  • Termux Settings Soft Keyboard Enabled: true/false
  • hide-soft-keyboard-on-startup:
  • soft-keyboard-toggle-behaviour:

If for above Hardware Keyboard Type=bluetooth, does it only happen with bluetooth keyboard or for usb keyboard as well?

Here you see the behavior of Termux + X11 in Split mode on a real device.

In this video the keyboard is showing so different from "OS-KB is never displayed".

Anyways, did this start on termux v0.114 or was it happening on previous versions too. If yes, then this is likely due to margin adjustment code e7dd0ee. It was expected that it would break on some edge case.

I need the logs to figure out what is happening. Set log level to Verbose and enable Termux View Key Logging toggle in termux settings, then run logcat command in termux. Trigger the bug, then post the log here with Share transcript in a markdown code block. No screenshots or videos! Thanks

@RalfWerner
Copy link

... there does not mean I understand what you are trying to say overall. And I don't have time to decipher it all.

I also accepted that and that we cancel the common search for solutions now.
Checks I performed on various real devices and AVD with Android versions of 8-11. In the discovered errors, bugs or my lack of knowledge (I say concerns) I have given what I used. Since you do not understand my descriptions, the video should be a reference to an open concerns. The 17 seconds video you should be able to repeat on all your split-enabled devices with v114.

... In this video the keyboard is showing so different from "OS-KB is never displayed".

If it interests you: the video above shows my Huawei-Y7/Android 8, mirrored with scrcpy and filmed with apowersoft. A shot is not possible because the flickers then can not be seen. The Extra keys of both splits are sometimes there, sometimes away and sometimes twice on unexpected positions. The OS KB is once there and finally away. Due to my screen touches, it would have appeared and disappear should be about 5-10 times. The topic BT/USB and PiP is not treated in the video. It can be repeated on all AVD. So also on your and yourself can produce a few thousand logcat lines.

If for above Hardware Keyboard Type=bluetooth, does it only happen with bluetooth keyboard or for usb keyboard as well.

All checks with BT=Blue Tooth I have done with identical effects with USB. So BT-KB=USB-KB. You've used another term: Hardware KB, with which the PC keyboard is meant using Android device mirrored (scrcpy, TeamViewer) on a PC monitor. This have a different behavior.

Most concerns I have with my PiP capable device. You have no and no emulator found so we continue talking different languages.

It is as if I wanted to explain an Android device to my mother 40 years ago. She would not understand me, even though she taught me speak. Today and with some time and patience it is no problem anymore. That she do not want to understand and learn the bash command Line with over 90, I can understand and accept.
In this sense, I will not make you nerves or spam you with my concerns.

AdamMickiewich pushed a commit to VolyaTeam/dzida-app that referenced this pull request Aug 8, 2022
…-not-showing-in-some-case

Fix issue where soft keyboard would not show in some cases
shrihankp pushed a commit to reisxd/termux-app that referenced this pull request Oct 20, 2022
…-not-showing-in-some-case

Fix issue where soft keyboard would not show in some cases
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
3 participants