Open echarles opened 2 years ago
Hi, I have listed the PR to consider for Android port and started to look if they were applicable or not.
But while doing that, I have tested the default editor with my Samsung (with the Chrome browser) and with the Android SDK emulator, connecting to the example where I was forcing the DefaultEditable
to be used (instead of the detected AndroidEditable
). They keyboard inputs were working fine for me (use the suggestions, copy/paste...).
I wonder if it is still useful to maintain adhoc implementation for Android. Could someone detail use cases to be considered to see if the DefaultEditor does a good job for Android?
Rectification: The DefaultEditable
does not work fine (double insertion...) with the Android emulator but works find with the Chrome being installed on my Android phone.
While reviewing the PRs, I have added Android to the exclusion case here https://github.com/ianstormtaylor/slate/blob/381f91b1dd47fc8f5279139b8957a2fae6180a5e/packages/slate-react/src/components/editable.tsx#L750-L762
Using android emulator, the double insertion is solved, and the text suggestion continue working. I have tried to use a bit more the editor, and it sounded to respond well.
I am pretty sure specific cases should be checked. Any hint on that ?
cc/ @wleroux @clauderic @bryanph @imdbsd
fyi The user agent returned by the android emulator is displayed in the following image.
Did more user testings, and the DefaultEditable has issues with Android. Still discovering here...
Keep in mind that the in-browser Android emulator in Chrome does not adequately reflect the behavior observed on an actual device... And different versions of Android will behave differently from each other. My hope is that the Android Chrome implementation eventually behaves the same as the Desktop Chrome implementation, however even if that is the case, it will still take a while for older devices to no longer be supported.
There is no specification (or consistency) for what events should be sent when typing using the smartphone keyboard. The AndroidEditable gets around this issue by processing the changes to the document structure and reverse engineering the required operations required to end up with the same document structure.
If you're trying to test the default implementation... try deleting/inserting paragraphs, deleting/inserting text at boundaries of bold/italics/underline (or deleting the entire node), word auto-completion, and non-English keyboards.
Thx @wleroux for the advice. Unfortunately I won't be able to work anymore on this.
My hope is that the Android Chrome implementation eventually behaves the same as the Desktop Chrome implementation, however even if that is the case, it will still take a while for older devices to no longer be supported.
It would be easier that Android Chrome provides Desktop Chrome compatibility. I wonder if a move forward would be to drop support for older devices.
The AndroidEditable should be maintained in parallel to the default Editable.
Looking at https://github.com/ianstormtaylor/slate/commits/main/packages/slate-react/src/components/android we may have missed bug fixes and features.
I will open PR to port the needed changes.
We can always start a discussion around the need for that specific AndroidEditable (I am missing context on the reasons for it).