Draft-js: Pressing 'delete' on an empty block before a styled block removes style

[remko]

Reproducable with the rich example:

• Hit 'return' to create an empty block
• Type something and make it an H1 block
• Go up to the empty block
• Hit 'delete' (or cmd-backspace)
• The H1 block is now an unstyled block

This doesn't seem intended behavior?
It doesn't happen in the FB Notes editor, though.

[hellendag]

Repros in the Notes composer for me, but I think this behavior isn't really wrong.

What's happening here is not that the first block is being deleted, but that the text from the second block is being pulled upward into the first block. The first block keeps its block type. This makes it appear that the first block was removed, and the second block was changed to be unstyled.

We could instead remove the first block completely, and move the cursor into the second block.

What do other editors do in this scenario?

[thesunny]

Just tested on a Mac.

Google Docs, Microsoft Word and Apple Pages all keep the H1 styles.

Just generally speaking, it feels like there are edge cases/unique handling for at least:

• delete on blank lines
• enter on blank lines
• enter on end of lines.

[hellendag]

Fair enough. It seems like that's consistent enough to change within RichUtils. I'm open to accepting a PR for this.

[alunyov]

In fact, in the Firefox, it doesn't delete the styling. But I can reproduce the steps in Chrome.

[remko]

@hellendag When you say RichUtils, you mean you'ld change it in RichUtils.onDelete, and assume the user that wants this behavior has handleKeyCommand hooked up to his component?

The alternative is to change the behavior in removeRangeFromContentState where the actual logic of joining the blocks is, making it default behavior.

[remko]

@hellendag _bump_ There's some comments spread around some issues and PRs on Draft block join/split behavior (this issue on joining, there's a mention about splitting on https://github.com/facebook/draft-js/pull/216#issuecomment-197979832, #188 on splitting blocks). Could you confirm which behavior you'd accept changes for where? I'm going to need these behaviors soon, so I'd like to figure out where it makes sense to create PRs for, and where to use external custom behavior.

To recap, the behaviors I'm thinking of (which seem to be pretty standard AFAICT):

• Join behavior:
  
  
  
  • Delete on blank lines: delete the current (empty) block. Change in onDelete? Does this ensure that all the cases are handled properly? (as raised in https://github.com/facebook/draft-js/pull/216#issuecomment-197979832 )
  
  
• Split behavior
  
  
  
  • Enter in middle of block: split the current block (current behavior).
  
  
  • Enter at end of block: Create an unstyled block after the current block.
  
  
  • Enter at end of empty LI: Unindent.
  
  
  • Enter at end of LI: Create a new LI at same level.
  
  

[hellendag]

Seems like RichUtils is the right place for this. If there are patterns that are common for Google Docs, MS Word, and others, I think it's fair to follow those conventions.

[sophiebits]

(copying comment from #266)

My impression is that this should be done at a lower level than RichUtils, like in DraftModifier.removeRange. In particular, here is where we choose to keep the preceding block's attributes:

https://github.com/facebook/draft-js/blob/bb6175cb5038acee8abec3c0a696e4eef5b30e01/src/model/transaction/removeRangeFromContentState.js#L53

It seems like the best way to fix this is to thread through a removalDirection boolean down to that function from all of its callers and choose whether to use startBlock or endBlock appropriately given that direction.

Note that RichTextEditorUtil does not currently handle this logic (DraftModifier and/or removeRangeFromContentState do), so I don't think it makes sense to try to work around that low-level "broken" behavior with a change in a higher-level module.

[tomconroy]

I think this is related: when I select the entire text of a block (including the trailing return) and press delete, it keeps the block type and pulls the text up from the following block. I expect it to cleanly delete the block.

[remko]

Probably also related: in the media example, there's no way of having just an image, there's always an unstyled empty block in front. If you hit 'delete' in an editor like Google Docs, it will remove the empty block and move the image up.