Draft-js: Atomic block isn't given focus

[mettin]

Do you want to request a feature or report a bug?
Bug (i think)
What is the current behavior?
I have a custom rendered component that has 2 inputs (<input type=number> and <textarea>). When pressing backspace in the first paragraph after this component I would expect it to be deleted. When pressing keydown in the paragraph before it, id expect my input to receive focus.

Steps to reproduce
http://read-time.herokuapp.com/ > Click 'edit text', type some text, click 'break' and try to delete the block.

What is the expected behavior?
Inputs receive focus and block is deleted when pressing backspace in the paragraph below it.

Which versions of Draft.js, and which browser / OS are affected by this issue? Did this work in previous versions of Draft.js?
All versions

Note: i think i should use <DraftEditorBlock/> but cant find any documentation on how to work with that.
Source: https://bitbucket.org/readtime/readtime-draftjs

[thibaudcolas]

From the perspective of Draft.js, your atomic block is contenteditable="false" so it doesn't know that there is any content within it capable of receiving focus. It might make sense to move focus like that for your use case, but this is far from common. You could probably implement this by handling the backspace command in handleKeyCommand.

For the "block is deleted when pressing backspace" part, you might want to have a look at https://github.com/facebook/draft-js/issues/1681#issuecomment-371143376 (the RichUtils.handleKeyCommand part), probably somewhere around https://bitbucket.org/readtime/readtime-draftjs/src/6b3e8e4b319a57d90dcb613653a3cc0548e1bf45/app/containers/App/index.js?at=master&fileviewer=file-view-default#index.js-417.

[mettin]

Thanks! that helps
Changing contenteditable allows the user to change the entire HTML of my component, which gives some freaky results =) Will fight a bit more with this.

The block deletion is fixed indeed!!

Thanks @thibaudcolas