Empty buttons on editing an existing page

[pascaloberhaensli]

Description

On editing an existing page multiple empty buttons are added without user interaction.

Step-by-step reproduction instructions

Go to all pages
Edit a simple page

Expected behaviour

I expect nothing to be added without user interaction

Actual behaviour

There are empty buttons somehow added during on loading of the edit-page screen.

Screenshots or screen recording (optional)

WordPress information

• WordPress version: 5.6 (5.6-de_DE)
• Gutenberg version: 8.6-9.2 (part of WordPress 5.6)
• Are all plugins except Gutenberg deactivated? Yes
• Are you using a default theme (e.g. Twenty Twenty-One)? No

Device information

• Device: Desktop
• Operating system: Windows 10
• Browser: Chrome 87.0.4280.141

[talldan]

@pascaloberhaensli I haven't been able to reproduce this or seen any other reports of this issue.

Curious that you get the same sequence of blocks two or three times—are they reusable blocks?

Would you be able to use 'Copy all content' from the editor options menu, and paste it here in a comment?

[pascaloberhaensli]

Thank you for your feedback. I did some more testing and I found out that the issue is more about that there are buttons in the code, but when you delete them (see GIF) than they are not deleted out of the code. Therefore the next time the page is opened, they are visible again. Interesting to say, that the publish of the page don't show the buttons if "deleted", but after close / reopen they are there again and if published visible.

After about 10 days not getting rid of the buttons, now it is possible that sometimes the buttons are deleted properly and sometimes not. Maybe an side effect caused by inactive/activate all plugins.

Code of an example with this behavior added below:

`

Testing

Text Text Text Text Text Text Text Text Text Text Text Text Text Text Text Text Text Text Text Text Text Text Text Text Text Text Text Text Text Text Text Text Text Text Text Text Text Text Text Text Text Text Text Text Text Text Text Text Text Text Text Text Text Text 

`

[talldan]

Thanks for the extra details, yes, I see this too now and have a good idea what's happening.

I can also explain how to remove your buttons. In your post each button consists of an outer Buttons block, which can contain multiple inner Button blocks. What's happening for you is that you're sometimes just deleting the inner Button, but not the outer Buttons container. When refreshing deleted button reappears if the container is still there.

When deleting, make sure you have the Buttons block selected, probably the easiest way is using the breadcrumb at the bottom of the screen, and making sure it looks like this:

and not like this:

If it looks like that last image, you can just click on the word 'Buttons' there to select the outer container.

---

As for the bug, it seems there are a couple of problems that are really confusing for users:

• When deleting the last Button in a Buttons block, the Buttons block becomes deselected and collapses to zero height (making it look like it's been removed)
• When refreshing, a button is recreated in an empty Buttons container which directly modifies a users content without their consent.

Steps:

1. Remove all Button blocks from the Buttons block
2. Observe selection of the Buttons block is lost and the block collapses to zero height
3. Reload
4. A Button block reappears.

[pascaloberhaensli]

Okay, thank you very much for your help. That works for us, but this is a very strange behavior. Would be great if an deleted button would stay deleted, even if an empty (obsolete) container is there. Or even better, delete the empty container, if the inner content is fully deleted (last button).

[annezazu]

This came up today in a triage session in #core-editor and I was able to confirm this behavior using Gutenberg 10.3.2 and WordPress 5.7:

delete.button.block.mov

This is a pretty frustrating and confusing experience right now so it would be neat to see this iterated upon!

[gwwar]

So what's essentially happening here is that the Buttons block has a default block of button. We automatically insert another button to help facilitate editing. I agree that this is pretty confusing behavior, when the parent container is not very visible and folks are removing items.

To help move this forward, what approach would be interesting to explore? To start with, a few that come to mind might be:

1. A smarter delete. Eg remove the parent container if all child items are removed AND the container is not visible in edit mode. (Eg we wouldn't do this for columns).
2. Somehow make the buttons container more visible. I do know that we're aiming for more 1:1 from edit/publish, so this might need to be specific to some mode.

cc @jasmussen @shaunandrews

[jasmussen]

My first instinct was to disallow removing the last Button in a Buttons block. However this won't work for us: due to the nesting, it isn't necessarily super obvious that the container has to be removed also.

I think what we should consider is to do what the Group block does:

When empty, even when unselected, it shows a big and obvious plus button to add content. In this case clicking the plus would just insert a single Button block inside as that's all that's allowed.

Longer term, this is opening up a question about the inner-workings of container blocks like these. It's essentially a group with flex-display: horizontal;, and if the group block lands that feature (#24473) it might be nice to have some code reuse going, both to bring benefits landing in one to the other, but also to unify the user experience. I discussed related work with @youknowriad a few days ago.

[shaunandrews]

When empty, even when unselected, it shows a big and obvious plus button to add content. In this case clicking the plus would just insert a single Button block inside as that's all that's allowed.

I'm not sure this actually resolves the problem, though. With the "big and obvious" inserter button, its almost harder to selected the parent Buttons block and delete it; As soon as you click it, your focus moves to the quick inserter and it becomes difficult to navigate to the toolbar, especially for keyboard users.

A smarter delete. Eg remove the parent container if all child items are removed AND the container is not visible in edit mode.

This is the behavior I would expect. If the Buttons block can only support button blocks, and I remove all the button blocks then the Buttons block serves no purpose and should be removed.

Alternatively, perhaps an empty Buttons block reverts to a placeholder-like state:

[talldan]

Just to add some more detail, the buttons block uses a template currently—when a buttons block is empty the template is used to create an empty singular button inside of buttons. That template is also created when first adding a buttons block.

I think a goal should be more consistency. That similar blocks work differently is probably one of the confusing aspects for users. I don't think any other block uses a template in the way buttons does, so maybe that should be removed and considered a failed experiment.

The placeholder idea makes sense to me, because that brings consistency with how social icons currently works.

Some screenshots of social icons for comparison.

Unselected:

Selected:

[jasmussen]

I'm not sure this actually resolves the problem, though. With the "big and obvious" inserter button, its almost harder to selected the parent Buttons block and delete it; As soon as you click it, your focus moves to the quick inserter and it becomes difficult to navigate to the toolbar, especially for keyboard users.

That seems maybe worth solving for every block that uses this big and obvious appender, actually! It'd be useful for the group, it'd be useful for columns. What do you think?

This is the behavior I would expect. If the Buttons block can only support button blocks, and I remove all the button blocks then the Buttons block serves no purpose and should be removed.

My concern with that is that we can't replicate this for every container block: you have to be able to insert an empty group block, or a columns block with empty columns. So the behavior between blocks would fragment further. In that vein, I'm echoing Dan above, that it's worth looking for constent behavior here, if it can be found.

A placeholder state could be an opportunity. But with the headaches we've had with the social inks setup state, I do worry that perhaps that pattern isn't as scalable as we hoped it would be.

[shaunandrews]

That seems maybe worth solving for every block that uses this big and obvious appender

Definitely. We've seen many times that the "big and obvious" button makes Columns very hard to use.

But with the headaches we've had with the social inks setup state, I do worry that perhaps that pattern isn't as scalable as we hoped it would be.

Oooh, what headaches?

[jasmussen]

@annezazu has been running excellent usertests across the site editor, and some of those have surfaced feedback about how the 3 colored social links dots looked like the social icons were already inserted and that perhaps social network properties defined for the WordPress user had been leveraged to configure them. The latest attempt at addressing that was the "Click plus to add" prompt you see above, which I also don't love as it goes further down the path of benefitting just one block as opposed to working in a more generic manner. In the same vein, the Navigation Block setup state has been reported to look a bit like it was loading with "skeleton indicators".

I still think that it's important to be able to insert those two blocks in their empty states and have them show something when unselected, it's likely going to be important for building templates. But the downsides have also shown themselves.

[aurooba]

Thanks for bringing this issue to my attention @annezazu!

This is the behavior I would expect. If the Buttons block can only support button blocks, and I remove all the button blocks then the Buttons block serves no purpose and should be removed.

I definitely would not want this to be the behaviour. In some of my client projects, we're doing a lot of user testing, and we consistently see people deleting the buttons rather than just editing the last button. They'll delete and then look for the inserter in the Buttons block to be able to add a new button fresh.

I have a draft PR (#38337) where I do add the big button block appender, but I don't make it span the width of the block, so it's easy to select the parent block if you want to get rid of it. Can that be the approach we take? I like how it differentiates from the main block inserter, because it's the outline style. It could be an edit we do for all container blocks.

[jasmussen]

Wanted to surface that #33025 exists as a potential solution for the inserters interactivity making it hard to select an empty group block. That might be less successful in case of, for example, the Row block where the inserter should arguably behave just as content added inside, i.e. not be full-width.