Fix error when anchorNode is missing in editOnInput

[eldh]

Fix for issue related to #1399. The fix is similar to #1407, in that it checks if anchorNode is falsy and if so bails.

[facebook-github-bot]

Thank you for your pull request and welcome to our community. We require contributors to sign our Contributor License Agreement, and we don't seem to have you on file. In order for us to review and merge your code, please sign up at https://code.facebook.com/cla. If you are contributing on behalf of someone else (eg your employer), the individual CLA may not be sufficient and your employer may need the corporate CLA signed.

If you have received this in error or have any questions, please contact us at cla@fb.com. Thanks!

[facebook-github-bot]

Thank you for signing our Contributor License Agreement. We can now accept your code for this (and any) Facebook open source project. Thanks!

[flarnie]

Hi @eldh!
I've been reconsidering the approach used in #1407 - it's true that according to the spec, anchorNode could be null. But why would that happen? And is it always correct to return in that case?
editOnInput gets called in a variety of circumstances, and I'm not convinced that this is the right fix.
It would be helpful to have a repro case and tests to demonstrate the problem.

[eldh]

Yeah, I agree it feels a bit weird. I'll dig a bit deeper! 👍

[eldh]

As to the question of why this happens: The case here is that the editor loses focus before editOnInput is called, so global.getSelection() will not be what is expected. More specifically, we have built a user mention feature where we display (and focus) user selection ui on typing @, moving the focus immediately. It's fairly easily fixed by delaying the focus change by one tick. But the question is if draft-js should make this assumption about the global state.

If not, is it correct to return in all cases? From what I can tell, the happy case on editOnInput is that it performs a bunch of actions on the anchorNode and related nodes. But before that, it does checks to check whether it should bail (isNotTextOrElementNode, isNotTextNode) early. I'd argue that it makes sense to include this case – nodeType is null – in the bail checks. Another option would perhaps be to throw a nicer error, with explanation on how to fix?

I'm probably missing a lot of context here, not sure in which other cases editOnInput is being called and what is expected in those cases. I'd be happy to try and write a test case at least.