-
-
Notifications
You must be signed in to change notification settings - Fork 3.7k
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
Consider using beforeinput
event on Android for typing and delete improvements
#3131
Comments
In fact, we could also check whether we couldn't base on |
After some initial testing it looks like the
|
We can go both ways – use |
Ouch, ignore my last comment. I see you covered everything in your message. |
I just wanted to sum up what I have concluded after few days of testing I have pushed some MVP branches which utilises Utilising
It seems it might be possible to reach some satisfactory improvement, but still |
I am picking this up now and want to summarize some of the research I did to get into the issue. There is a lot of information in a lot of posts added across various issues and it is hard to follow that, especially since some of that already got outdated either due to changes in our code or due to changes in browsers. For that reason, I want to sum up once again what's going on and what problems we have with typing on Android. Thanks to @f1ames for setting foundations for that. So, deleting is incorrectly handled on Android. For non-collapsed selection, twice as much content is deleted than it was selected. At the beginning, I thought it is a lot of magic, quirkiness and nonsense but after digging deeper and deeper I think that we might be able to do something there. Okay. How does it happen? tl;dr: Input handling differs a lot between Android and desktop and we need to cater our algorithms for those differences. Not sure if one-solution-to-fit-all will be possible. On Android, the content is first removed programmatically by us (in one of the event handlers) and then also remove mutations are generated because our events handling algorithms are not suited for how Android Chrome behaves. First of all, deletion is not recognized as deletion because in We have If the content is deleted, then the selection is set to be collapsed. This is where the problems start. Selection behaves differently on Android than it does on the desktop. I am not sure if it is a browser's fault (Android Chrome vs desktop Chrome) or IME's fault (virtual keyboard vs physical keyboard). So let's see what happens using plain contenteditable without CKE5. We will test Backspace and R on non-collapsed selection. I modified @f1ames codepen to check what exactly happens: https://codepen.io/anon/pen/rELxwd?editors=1010. You can uncomment and change the Desktop Backspace scenario. It works the same for collapsed and non-collapsed selection:
Desktop R scenario:
What happens on Android though is more magical. I am sure it can be somehow explained given that all virtual keyboard input is treated kind-of-like-IME-or-composition (according to Chrome devs/docs). But, unfortunately, it differs from what happens on a desktop by quite a lot. Android Backspace scenario:
Android R scenario: First of all, if the selection was non-collapsed, there are two "actions" performed here. First is deletion and it works like above. Then events for "insert
The next step was to check how changing DOM selection in events callbacks affects what happens on Android:
At this point, I was happy with the research I've done. I understood how typing works on Android and how to change our scripts to handle it correctly. Then I decided to switch keyboard to GBoard and see how it works. And I got extremely disappointed. It seems that GBoard is the default keyboard, while I tested Switfkey (which is default on Huawei). Honestly, I didn't think which one I am testing and that the differences might be so big. So, long story short GBoard treats every typing as composition. This is because of auto-correction / word suggestions (when I turned them off it started to work similarly to Swiftkey). I guess one could argue that it makes some sense 🤷♂but really it wasn't something I expected. So, fired events, their data, selection behavior, browser reacting to selection change on events -- it is all different. Even removing a character is treated as a composition change and Fortunately, removing selected content generates events as on Swiftkey. Unfortunately, replacing selecting text does not provide two events as on Swiftkey. Instead, one After this research, it is obvious that our current solution won't work well on Android. Our handling is done on We cannot go fully into So, I think that we need dedicated handling on |
Did you try also Samsung keyboard? I had to install GBoard on Samsung as they provide their own keyboard. Also this might be relevant to other vendors. |
Samsung keyboard, pre-installed on Samsung devices, works even differently 😵😵😵. From a very quick check, it looks like it works similarly to Chrome desktop. It fires correct |
PLOT TWIST: When you switch to Chinese (Pinyin) on GBoard, it starts to behave like Samsung keyboard, that is, when using Backspace, it suddenly starts sending "correct" |
Feature: Improved typing on Android devices by handling `beforeinpnut` event. Introduced `options.selection` in `DeleteCommand` params. Introduced `selectionToRemove` parameter in `view.Document#event:delete` data. Closes #167.
Some time ago @szymonkups did some research regarding typing on Android and
beforeinput
/input
events - #614 (comment). At that time it doesn't seem reasonable to go with those events as they didn't bring much improvement for what we had.Now, when we started working on typing improvements for Android - #614, we have revisited those events and the way they can help improve typing.
Since
beforeinput
andinput
events are available on Android 6+ now (tested on Android6.x
and8.x
with Chrome67.0.3396.87
on this fiddle) we should reconsider utilising them especially that we have encountered some not so trivial cases while working on Backspace support - #3126, #3129, #1127.One idea is to integrate
Delete
plugin withbeforeinput
/input
as for content removal it always has adeleteContentBackward
flag, so it could be used instead or together with ckeditor/ckeditor5-typing#165. However, it might be tricky to integrate withinjectUnsafeKeystrokesHandling
askeydown
event is fired beforebeforeinput
and thekeydown
handler modifies DOM content.The other thing I have noticed (Android
6.0.1
) is that events sequence is not always the same, could be:or:
depending on what is removed I suppose (the fact that some events sequence is not always the same is also mentioned here).
So while it seems reasonable to recheck if those events could bring some improvements for typing on Android, we need to make sure to do proper testing.
The text was updated successfully, but these errors were encountered: