Closed rgossiaux closed 6 years ago
We don't have any Android use cases in production right now, so I can't vouch for its behavior. Sorry about that. :(
IIRC, the issues involved are covered in https://bugs.chromium.org/p/chromium/issues/detail?id=118639.
I'd love to see a version that works well in Android, but I haven't tried to tackle it myself.
Oh, I see -- does FB intend on using this on Android any time soon?
Do you have a sense of how difficult it would be to support this case, or for someone else to fork and fix?
I don't believe we are trying to solve Android at FB at this point. Previous attempts were made, but nothing shippable emerged.
Some Android version/browser cohorts may be working fine already, I'm not sure.
I'd be delighted to see a fork that tries to take it on. I'm not likely to have time for it soon, unfortunately.
The following two statements in the documentation suggest cross browser support
abstracting over cross-browser differences
Draft.js is used in production on Facebook, including status and comment inputs, Notes, and messenger.com.
Is it possible to add what browsers are supported and what environments facebook use it with in production?
Something along the lines of MDN's Browser Compatibility table with the known state would be amazing.
Slowly trying to make it working for Android: https://github.com/facebook/draft-js/pull/175
entering "C'etait"
Composition is mixed with EditOnInput and EditOnBeforeInput
2016-03-08 04:19:43.073 bundle.js:109692 Composition: C' ==> here the keyboard disappear 2016-03-08 04:19:46.379 bundle.js:116854 Edit on beforeInput: e 2016-03-08 04:19:46.495 bundle.js:117296 Edit on Input: C'e 3 3 2016-03-08 04:19:48.984 bundle.js:109692 Composition: C'etait
the inserted text become: C'eC'etait
instead of C'etait
because the composition was intending to replace some text already entered.
Another note.
restoreEditorDOM
in resolveComposition
is responsible for making the keyboard disappear during typing.
When the composition starts, some text can be selected to be replaced. This happens when the composition starts in the middle of a word but the whole word is being composed.
compositionStart receive the text being modified in data.
composition fixed :)
@cgestes give me a shout if you need help testing anything
You guys are great. :) Thanks for taking this on.
Hey all, I'm also blocked on this (#175). Thanks for looking into it. In the meantime, anyone know of workarounds for Android?
I don't believe we are trying to solve Android
I don't see how this statement can be reconciled with the marketing on draftjs.org. The documentation should really be updated to make it clear that this isn't a cross-browser solution. The marketing of this project is misleading, and it's causing unexpected pain for a lot of people.
It states that abstracting over browser differences is a core goal, and it's mentioned on the readme that it's used in production by Facebook, which gives the impression that this is a cross-browser solution - but it barely functions on the most popular mobile web browser in the world. As far as I can tell, the team isn't investing resources to fixing the issue, either.
I have worked in Android with draft.js for half year to make a rich editor. Our app is ready for releasing now.
The real hard thing to work with Android is that some Android input methods not send any key press event but use InputConnection to control the content via directly API like deleteSurroundingText
. Because draft.js does some key event processing, the things goes wrong.
@jan4984 did you find solutions? Could you share, if so? I've been hacking around things but haven't found any really reliable solutions...
@iEchoic I found this paragraph at the very bottom of the "Issues and Pitfalls" page... but only after discovering by experience that Draft.js totally fails on Chrome for Android. I agree with you, it would have been nice if that was more clear from the get-go.
@iEchoic yes. the most easy way is wrapper the InputConnection, and send keys. like:
@Override
public boolean commitText(CharSequence text, int newCursorPosition) {
if(TextUtils.isEmpty(text)){
//lot's of IME to commit empty text while backspace pressed, convert it back to backspace press
super.sendKeyEvent(new KeyEvent(KeyEvent.ACTION_DOWN, KeyEvent.KEYCODE_DEL));
return super.sendKeyEvent(new KeyEvent(KeyEvent.ACTION_UP, KeyEvent.KEYCODE_DEL));
}
return super.commitText(text, newCursorPosition);
}
@jan4984 . Would you please provide more context on how to wrap InputConnection
? I'm not being able to make https://github.com/andrerpena/react-mde to work on Android 😢
Thank you!
Merging this into a general Android bug issue - see https://github.com/facebook/draft-js/issues/1895
@jan4984 How exactly did you get that code to work? (I'm working with an older version of Draft.js being used on a website I don't own/program). On Android 10, when trying to use that wrapper you provided, the app instantly crashes.
@TheAlienDrew sorry Android version goes fast. I not work it for 3 years.
Autocorrect very quickly breaks the editor. On a Nexus 4 with the default keyboard, if I do this:
1) Focus the editor 2) Type 'T' 'h' 'i' 3) Hit space. It autocorrects to 'This ' and the editor loses focus. 4) Refocus the editor at the end of the line. 5) Hit delete three times, to get to 'Th' 6) Hit 'i' 's' and then space.
At this point you expect the text to be "This ", but in fact after the space it becomes "Th". And now the editor is in a bad state, and continued typing produces unpredictable results, e.g. hitting backspace followed by 'i' at this point gives you "Thisi".
More generally, you get unpredictable behavior very quickly by just combining normal typing, autocorrect, and delete.