-
Notifications
You must be signed in to change notification settings - Fork 4.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Update heading block on ENTER key to create empty paragraph instead of heading #10382
Update heading block on ENTER key to create empty paragraph instead of heading #10382
Conversation
Worth noting that this bug is also addressed in #11005, but it's cool if I can be done without it. |
@andrewserong do you plan to continue working on this PR? It looks like the changes which @iseulde referenced are much broader but you would have to validate yourself how much overlap there is. |
f6c830e
to
0bf392e
Compare
@gziolo and @iseulde — I've fixed up this PR, updating the order of Looks like the tests are passing now, but I'm also aware that I haven't added e2e tests for this specific behaviour. It looks like particular blocks aren't targeted in the existing e2e tests, so I wasn't sure if behaviour specific to the heading block should be covered or not? The other consideration is that this PR works with the current |
I think it's ok to add the fix, but we should definitely add e2e tests. :) |
… instead of heading (WordPress#10326) The onSplit method for the heading block will now replace an empty heading block with an empty paragraph block for the 'before' content. This allows the ENTER key pressed at the beginning of a heading to create an empty paragraph above it. Also, when the ENTER key is pressed at the end of a heading, an empty paragraph block is created below, instead of another heading block. The RichText component now also calls event.stopImmediatePropagation() before splitContent() to prevent TinyMCE from throwing an error. This avoids a similar error as in WordPress#4580.
Since my last commit, the behaviour of onReplace seems to have changed a little bit. This commit ensures that an empty paragraph is added before a heading if a heading is 'split' with no before text, but with some after text (e.g. if the carat is at the beginning of a heading and the user presses ENTER) Also removed unnecessary `event.stopImmediatePropagation()`.
e512f16
to
ca48320
Compare
This ensures that if a user types a heading, then moves the caret to the beginning of the line and presses ENTER, that a paragraph block is created above. Also ensures that when a user presses ENTER at the end of a heading, a paragraph block is created below.
ca48320
to
69fc7cc
Compare
Nice addition with tests. Let’s merge it as is after some testing in that case 👍 |
8cc648a
to
1c398b6
Compare
Thanks for the feedback @iseulde! I've moved the tests up to the heading block tests, and removed the extra active class check. |
Something strange happens when merging back:
|
I could live with it being transformed to a paragraph block, but the caret moving to the end is very unexpected. This doesn't happen in |
@@ -5,6 +5,8 @@ import { | |||
clickBlockAppender, | |||
getEditedPostContent, | |||
createNewPost, | |||
insertBlock, | |||
pressKeyTimes, | |||
} from '@wordpress/e2e-test-utils'; | |||
|
|||
describe( 'Separator', () => { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Not introduced in this PR, but this title is not correct. 😅
Oh, thanks for spotting that! Yeah, that's not meant to happen. I'll take another look and see if I can work out what's going on... |
I'm a little bit stumped by this issue — it feels to me like it's got to do with how |
I've done a bit more investigating, and I think there might be an issue that exists on Master that affects the behaviour here. If we have an empty paragraph block that already exists, and press backspace at the beginning of a heading block, the paragraph block above is removed, and the caret sits at the beginning of the heading as we would expect. It looks like this issue only occurs on paragraph blocks that have been created above by the heading block when it's split. So it looks like there's something different about the block that was 'created' by the heading block onSplit than a standard paragraph block — even though the code editor view of the block remains the same. The issue that I noticed on Master occurs if you create a heading, then move the caret to the beginning of the line, and then press ENTER. The heading moves down to a paragraph block as we would expect, but the empty heading block now has two My hunch at the moment is that whatever it is about this block that gets created from the Heading block when a user hits ENTER is causing it to not do what we expect it to when we want to merge those blocks again. If that makes sense! Since this issue is affecting this PR, I'm happy to keep investigating when I have time, but I don't want to hold anything up if there's a desire to get this one merged in. Let me know, and I'm happy to open a new issue for this. |
@andrewserong Thank you for the work you've done here! I've refactored selection state in #14640 and now #14765 will revise the |
@ellatrix That's great to hear, thanks for letting me know! |
Resolves #10326
Description
This PR tweaks the behaviour for the heading block when a user presses ENTER at the beginning of a heading (as mentioned in #10326).
This allows the ENTER key pressed at the beginning of a heading to create an empty paragraph above it. Also, when the ENTER key is pressed at the end of a heading, an empty paragraph block is created below, instead of another heading block.
I realise this could be a matter of personal preference, but to me this feels like a more natural behaviour when writing long-form prose, where the default block would seem to be the paragraph, and I assume a user creating headings would want to switch back to a paragraph block instead of creating multiple heading blocks.
How has this been tested?
Unit tests and linting is passing locally. Tested in Chrome 69 and Safari 11.1.1 on macOS 10.13.5.
Screenshots
Types of changes
onSplit
method in the heading component.Checklist: