Block option 'edit visually' and 'edit HTML' still available when block is in warning state

[johngodley]

If you put a block into a warning state (edit HTML and remove some tags) then the block option 'Edit visually' and 'Edit as HTML' are still available and seem to toggle state, but have no apparent effect on the block.

For simplicity they should probably be removed while the block is showing a warning.

To Reproduce Steps to reproduce the behavior:

1. Type some text in a block
2. Edit the block as HTML
3. Remove the trailing </p> tag
4. Click outside the block to show a warning
5. Click the blocks options to see that 'Edit visually' is still available and toggles to 'Edit as HTML' if selected, but with no change in the block

Expected behavior The 'Edit visually' and 'Edit as HTML' to be disabled or not present in the menu. I think it will cause confusion when they don't do anything.

Screenshots Block in warning state shows edit option:

Clicking this toggles the option but has no outward effect:

[aduth]

Is there a workflow we'd want to support where a user is presented with the warning and desires to take it upon themselves to attempt the repair via Edit as HTML ?

[johngodley]

Is there a workflow we'd want to support where a user is presented with the warning and desires to take it upon themselves to attempt the repair via Edit as HTML

That's a good question. It could be frustrating to edit HTML, make a small mistake, and then not be able to correct it straight away.

The invalid block warning message seems to be a block-scoped 'modal', and as such it probably makes more sense if a 'edit as HTML' option is presented in the warning itself along with other recovery options.

Note that #7741 adds a dropdown menu where this could happen inline without adding too many buttons.

Side thought, but I'm also wondering if it makes sense for the block's dropdown menu to disappear entirely? None of the available options seem useful until the warning has been resolved, and it reduces the modal-ness of the warning. However I'm unfamiliar with the thinking behind the menu.

I've disabled the menu option in #7886. I don't know if it makes sense to go with that for now to 'fix' the current behaviour (which feels a little buggy), and see about allowing a re-edit HTML option after?

[aduth]

I landed here after glancing at #7886 . I might agree about removing the dropdown altogether. The one that could be argued to be useful would be "Remove", which should also be possible by Backspace (if not, a bug), but this isn't always obvious to a user either.

I don't know that #7886 is much of an improvement over the current state, and may even introduce some of its own confusion ("Why is the button disabled?") .

[johngodley]

@jasmussen, appreciate your design thoughts here. Should the 'edit as HTML' option be brought into the invalid block warning and the block dropdown menu disabled entirely while a block warning is shown? Or should the 'edit as HTML' remain in the block dropdown and be made to function correctly?

7886 can be dropped in either case as it only covers up an existing problem. Being able to re-edit block HTML seems a better solution.

[jasmussen]

This is an interesting challenge.

My very first instinct is the same as yours: there should be a way for the user to repair the block on a per block basis rather than have to set the whole editor to HTML mode.

However a block is a block, even if it has a warning, so I don't think we should remove either the movers or the ellipsis. I also think the "Edit as HTML" option should remain in the dropdown for the reasons mentioned above. Should we in addition to this add a button on the warning itself? Not sure, in general I would hope that we could avoid two buttons that do the same, especially because if we add that button, then how do you get back from html mode once you fixed it? The answer at that point is through the dropdown.

This could be an argument for making the block ellipsis more visible than it is right now. As I consider that, I would lean towards us keeping the Edit as HTML options where they are.

[johngodley]

I've closed #7886 in favour of #9088 which allows a block to be re-edited as HTML. This leaves everything in place as Joen described, allows the problem to be corrected more directly, and fixes this issue.

[ZebulanStanphill]

This could be an argument for making the block ellipsis more visible than it is right now. As I consider that, I would lean towards us keeping the Edit as HTML options where they are.

If the ellipsis is moved into the block toolbar as proposed in #9074/#9282, will it still be visible when the block is invalid? Currently, the block toolbar is not shown when the block becomes invalid, though I guess you could still show the ellipsis even if the rest of the toolbar is hidden.

[azaozz]

Related: #9571. The idea there is to either completely remove "Edit as HTML" from the ellipsis menu for blocks that don't support editing of their HTML, or to replace it with a "Convert to HTML block". Either would solve this issue.

[enriquesanchez]

Hi folks!

I'm doing some clean-up and triage of issues and was wondering if this one is still valid. I can see that the current version of the Gutenberg plugin shows a different UI when a block is invalid:

[jasmussen]

I'm afraid it's still an issue:

[jordesign]

Noting this is still an issue in WP 6.3