Make WordPress Core

Opened 2 years ago

Closed 2 years ago

#54652 closed defect (bug) (fixed)

Hitting Backspace In the Reusable Block Naming Modal Deletes Modal and Selected Blocks

Reported by: jeffr0's profile jeffr0 Owned by:
Milestone: 5.9 Priority: high
Severity: normal Version: 5.9
Component: Editor Keywords: has-testing-info commit
Focuses: Cc:


In WordPress 5.9 beta 3, I discovered the following bug. When selecting multiple blocks and adding them to a reusable block, in the modal that provides a way to name the reusable blocks, hitting the backspace key not only removes the modal from the screen, but all of the blocks that were selected are deleted.

I was not able to recover those blocks using Control Z. I ended up having to restore my content from an earlier save. The expected behavior is for the modal to allow me to erase characters in the case of fixing a typo. This bug can cause a loss of content.

How to reproduce:
Step 1: Create a few different blocks
Step 2: Select all of those blocks
Step 3: Click the three dots and Add those to reusable blocks.
Step 4: When the prompt comes up to name the reusable blocks, hit the backspace key.

Attachments (1)

test-attempt-to-reproduce-54652.gif (3.6 MB) - added by hellofromTonya 2 years ago.
Test: Attempt to reproduce reported issue on macOS Big Sure. Results: backspace does delete content; control Z restores the content.

Change History (13)

#1 @kraftbj
2 years ago

  • Milestone changed from Awaiting Review to 5.9
  • Priority changed from normal to high

2 years ago

Test: Attempt to reproduce reported issue on macOS Big Sure. Results: backspace does delete content; control Z restores the content.

#2 @hellofromTonya
2 years ago

Test Report


  • OS: macOS Big Sur
  • Browsers: Chrome, Safari, Edge, and Firefox
  • WordPress: trunk, 5.9 Beta 3, and 5.8.1
  • Theme: TT2 for 5.9, TT1 for 5.8.1
  • Plugins: none
  • Localhost: wp-env and Local

Steps to Reproduce

  1. Add a new post
  2. Add more than one block
  3. Select more than one block
  4. Press enter or click on the : to open the modal
  5. Select "Add to Reusable blocks"
  6. Start to type something in the modal
  7. Then backspace to clear it

Result: Notice with 5.8.1 the modal stays open and the content is not deleted. Notice with 5.9, the modal closes and the content is deleted.

  1. With 5.9, press control+Z.

Result: Should restore the content.


I am able to reproduce the modal closing and the content being deleted when pressing backspace. However, I'm not able to reproduce the content not being restored when pressing control+Z. The content does restore for me in all 4 browsers.

#3 @hellofromTonya
2 years ago

  • Keywords reporter-feedback has-testing-info added

Hello @jeffr0,

Welcome to WordPress Core's Trac! Thank you for reporting this issue with 5.9 beta 1.

In testing on macOS Big Sure with no plugins activated and using Twenty Twenty-Two (TT2) theme, I was able to reproduce backspace deleting the content, but not able to reproduce control+Z not restoring the content. I got the same results when activating the latest version of Gutenberg.

The behavior of closing the "Create Reusable Block" modal and deleting the content on backspace seems incorrect to me. This behavior is different from 5.8.1 which keeps the modal open and the content intact. I'll open a Gutenberg issue to report that upstream for resolution.

I'm curious why control+Z does not restore the content for you. Can you check this please? Highlight some content and delete it. Then do control+Z. Is the content restored?

If no, please open Dev Tools in your browser (typically by right clicking and then selecting "Inspect" or "Inspect Element"). Then go to the "Console" tab. Are there any errors in the console?

#4 @hellofromTonya
2 years ago

Reported the issue upstream in the Gutenberg repository where it'll need to be investigated and resolved. Once resolved and merged into Gutenberg, the fix will be backported to WordPress Core as part of a backport package update.

Discussion, testing, and feedback should shift to the issue in Gutenberg to empower the Editor team in identifying and resolving the issue.

#5 @costdev
2 years ago

For reference: I can reproduce on trunk using TT2, including that Ctrl+Z doesn't restore the content (unless it was previously saved in a revision).

I've narrowed the issue to an event listener and I'll comment upstream to help the team resolve the issue.

#6 @hellofromTonya
2 years ago

  • Keywords reporter-feedback removed

Cool, thanks @costdev. Removing reporter-feedback keywords as Ctrl+Z is reproducible.

#7 @codeamp
2 years ago

I think this might be related to this old issue (I opened)?

Essentially, you would expect keyboard focus (and shortcuts) to be handled in the input in the the opened modal, but instead they are handled by the editor underneath.

Not 100% they are the same issue but I think there is some overlap.

#8 @costdev
2 years ago

A note that this has already been reported as an issue upstream here and has a PR that will also be tested with the Delete key and updated if that needs to be included as well. The issue mentioned earlier in this ticket by @hellofromTonya has been closed and the discussion moved to the original issue.

@codeamp I don't believe that this is the same issue. However, the Backspace/Delete problem may have created a scenario for reproducing the Ctrl-Z behaviour raised in the issue you mentioned.

#9 @codeamp
2 years ago

Ah ok thanks for the update. I see now it looks like a regression that probably highlighted the issue I previously reported (which is now worked around by preventing event propagation).

My guess would be that issue I linked is still visible by pressing ctrl + z while the modal is up (after entering text) - but I guess that also existed pre 5.9 so I'm probably going off topic a bit 🙄

Version 2, edited 2 years ago by codeamp (previous) (next) (diff)

#10 @costdev
2 years ago

Looks like we have a fix merged upstream with 4 manual tests and automated tests included - looking forward to the backport so we can close off this ticket.

#11 @hellofromTonya
2 years ago

  • Keywords commit added

When @noisysocks does Gutenberg's backports update, will be included. Marking this ticket for commit to move it out of the WIP ticket queue. Will close this ticket once the the backports are committed.

Committer: The commit for this ticket should be included in the next Gutenberg update. Please verify before closing this ticket.

#12 @hellofromTonya
2 years ago

  • Resolution set to fixed
  • Status changed from new to closed

Fix was backported in [52434].

Note: See TracTickets for help on using tickets.