swiping up from the top row dismisses the keyboard partially

ubports / keyboard-component

Moved to https://gitlab.com/ubports/core/lomiri-keyboard

https://gitlab.com/ubports/core/lomiri-keyboard

GNU Lesser General Public License v3.0

10 stars 36 forks source link

swiping up from the top row dismisses the keyboard partially #111

Closed Fuseteam closed 3 years ago

Fuseteam commented 4 years ago

swiping up from the top row dismisses the osk partially this is rather annoying for flick keyboards( #93 ), but it is also rather difficult to reproduce reliably the only way i have been able to reproduce this reliably is by opening the osk in portrait and rotating the phone to landscape it also happens in portrait occasionally but i have not been able to reproduce it any help finding the files responsible for swipe to dismiss is welcome

Fuseteam commented 4 years ago

this may or may not be related to #42 further research needed

cibersheep commented 4 years ago

Hello.

Is this still an issue?
Is «top row» the indicators bar?
Could you add steps to reproduce?

Thanks

Fuseteam commented 4 years ago

yes it is still an issue the the top row of the keyboard it is rather difficult to reproduce but one way is to do the following

open the keyboard by say going in a telegram group
while the keyboard is up rotate you device
swipe up from say the q

notes: this problem is much more annoying in with flick keyboards like the japanese layout it also happens sometimes without rotating but i have not been able to figure out how to trigger it disabling autocomplete seems to workaround the issue

cibersheep commented 4 years ago

I have selected Japanese keyboard and try to reproduce. Tried rotate the device with OSK visible:
- swiping up from different character in Japanese keyboard
- swiping down to dismiss keyboard
I have also tried in Catalan keyboard (rotating the device with OSK visible):
- selecting 1 from q (swiping up, even if it's not needed)
- Tried to dismissing keyboard swiping down.

I couldn't reproduce on Arale Dev channel. More investigation is needed I guess

Fuseteam commented 4 years ago

even rotating while the osk is open didn't reproduce it? dang this one is difficult te reproduce :v

cibersheep commented 4 years ago

even rotating while the osk is open didn't reproduce it? dang this one is difficult te reproduce :v

I forgot to mention that in all cases I had the OSK up and rotated the device a couple of times

Fuseteam commented 4 years ago

@cibersheep did you swipe up from the actual charkeys? like say the q on the standard qwerty keyboard not unlike how you type "c" on the japanese keyboard ah perhaps i should also mention the osk should be up in portrait then you rotate to landscape while it's up before swiping up from one of the top row of keys at least spellcheck should also be enabled

cibersheep commented 4 years ago

Oooook... it took a while but I was able to reproduce :)

Steps to reproduce:

tap and hold a character from the keyboard (one fro the top row is easier)
before the extended keyboard shows / gets the focus, swipe to the top side of the keyboard
swipe down

Touch is capture for the keyboard dismiss Touch area

keyb2

Full video:

keyboard-video-mp4.zip

Fuseteam commented 4 years ago

finally someone manageed to reproduce it :joy:

Fuseteam commented 4 years ago

wait that just looks like the regular gesture to dismiss the keyboard :thinking:

cibersheep commented 4 years ago

wait that just looks like the regular gesture to dismiss the keyboard thinking

I'm pressing y but what happens is the touch goes to the dismiss keyboard area (I suspect)

Fuseteam commented 4 years ago

ohw your just pressing y, yeah that's the weird behavior, turn autocorrect off seems to word around the issue fwiw

cibersheep commented 4 years ago

I have autocorrect off, only word suggestion. Is the same behaviour with it on or with all language aids off (top ribbon with suggested words not visible).

Fuseteam commented 4 years ago

yes i mean turning word suggestion off

Fuseteam commented 3 years ago

i found these logs by running maliit-server with MALIIT_DEBUG=true

DEBUG: Updating input method area to QRegion(0,623 1280x46)
DEBUG: keyboard is reporting <x y w h>: < 0 623 1280 46 > to the app manager.
DEBUG: Updating input method area to QRegion(0,603 1280x66)
DEBUG: keyboard is reporting <x y w h>: < 0 603 1280 66 > to the app manager.
DEBUG: Updating input method area to QRegion(0,586 1280x83)
DEBUG: keyboard is reporting <x y w h>: < 0 586 1280 83 > to the app manager.
DEBUG: Updating input method area to QRegion(0,570 1280x99)
DEBUG: keyboard is reporting <x y w h>: < 0 570 1280 99 > to the app manager.

it looks suspiciously similar to the logs it spews when actually dismissing the keyboard

Fuseteam commented 3 years ago

considering it looks suspicously like what it logs when dismissing the keyboard i grep the repo for keyboard is reporting and found it only leads to https://github.com/ubports/keyboard-component/blob/ed3c5fbf2a820f194ed2172e8ad2fd729bd4a3b9/src/plugin/inputmethod.cpp#L632-L653

peat-psuwit commented 3 years ago

Hello,

Thank you for contributing to UBports. As part of project renaming and the effort to port Ubuntu Touch stack to Ubuntu 20.04, we're incrementally migrating repositories to GitLab.

Your issue is now migrated to: https://gitlab.com/ubports/core/lomiri-keyboard/-/issues/111

Sorry for your inconvenience.