Open joshfarrant opened 6 years ago
@joshfarrant I am experiencing the same issue. Would you know if there are any workarounds for this ?
No, not that I've found. My 'solution' has been to fork the emoji plugin and filter out the problematic emoji so they can't cause a problem.
That's not really a solution though. I'd like to see someone with a bit more knowledge of the core of draft-js have a proper look into this issue, as it's quite clearly a bug (and an easily reproducible one at that).
Josh Farrant - Senior Developer at Nimvelo
On 24 Feb 2018, 19:51 +0000, Darwin Carrillo notifications@github.com, wrote:
@joshfarrant I am experiencing the same issue. Would you know if there are any workarounds for this ? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.
Does anyone with any more knowledge about the specific API mentioned in the original issue have any input on this?
any progress?
Do you happen to have a list of problematic emoji? Could we make a PR to the draft-js-emoji plugin to filter those out by default?
Any progress here?
Any update?
In DraftEditorBlock.react.js (L190), certain strings cause
leavesForLeafSet.first().get('start')
to incorrectly report the start position of the string.For example, entering any of the emoji digits from 0-7 (0️⃣ - 7️⃣) causes
leavesForLeafSet.first().get('start')
to incorrectly return the start position as 1, rather than 0. Oddly, entering either 8️⃣ or 9️⃣ works as expected and the start position is correctly returned as 0.This doesn't appear to have any negative effect on a basic
<Editor />
, however it becomes an issue when using the emoji plugin as thedecoratedText
prop that draft-js passes through to it ends up being an emoji modifier character (⃣).You can see this in action by trying to enter any of the 0️⃣ - 7️⃣ emoji into the first demo (Simple Emoji Example) on the emoji-plugin docs site. (Related issue in draft-js-plugins repo).
Fixing the inconsistencies with
leavesForLeafSet.first().get('start')
so that it consistently returns the correct start position of all numeric emoji characters would resolve this issue.Tested with v0.10.5 of draft-js on MacOS 10.13.1