Custom HTML block - invalid markup results in block validation issue with incorrect conversion option

[talldan]

Describe the bug
When a user inputs invalid html into the Custom HTML block, it triggers a block validation failure. Furthermore, the options presented for resolving the validation failure don't seem to be appropriate for this block.

To Reproduce
Steps to reproduce the behavior:

1. Create a new post and add a Custom HTML block
2. Paste in the following invalid HTML (a table with a missing tbody element):

<table>
  <tr>
    <td class="test">test</td>
  </tr>
</table>

3. Save the post and reload the page
4. Observe that the block fails validation
5. Click on 'Convert to HTML'
6. Reload the page
7. Observe that the block still fails validation (the option to convert was unhelpful).
8. Click on Resolve
9. Observe that the resolution dialog has two options, the 'Convert to HTML' option does the same thing as step 7. The 'Convert to Blocks' option converts the block to a table block, potentially stripping out custom html the user might have added.

Expected behavior
I think there are three main issues:

• From a user's perspective, at no point in the process are they given any information on what the actual issue is and we can't expect every user to be able to write standards compliant HTML.
• The 'Convert to HTML' invalid block resolution option, while helpful for other blocks, doesn't make sense for the HTML block.
• The 'Resolve Block' dialog should ideally not try to convert a Custom HTML block to another matching block type. If the process instead kept the block type and offered to resolve the invalid HTML (as shown in the screenshot of the console error), that would be very helpful option for the user.

Screenshots
Resolve Block dialog

Console error for block validation

Additional context

• This seems to have been originally reported in the block audit but wasn't followed up on.
• 4.7..1

[chrisvanpatten]

I'm running into this as well; I have a 3rd party embed in an HTML block which has a camel cased custom HTML attribute that the parser thinks is invalid (actual: paypalExpress="false"; expected: paypalexpress="false").

Strange that it's the camel-casing being picked up and not the fact that paypalexpress isn't a real HTML parameter, but there ya go!

[designsimply]

@talldan #12448 looks related and reports a problem where using both & and & in a Custom HTML block invalidates it. Can that issue be consolidated with this one or do you think it should remain open as a separate issue?

[fastlinemedia]

@chrisvanpatten can you try pull request #13406? It fixes issue #12448 and looks like it could fix this too.

[talldan]

Hey @designsimply - sorry for the slow response. I think they are duplicates, yep.

I've also just noticed the HTML preview seems to be broken on master, not sure if anyone else is able to reproduce that. I just see what seems like a collapsed element with a horizontal scrollbar in the preview:

I'll create an issue to cover that.

edit: that issue seems to only be for some themes, created this issue #13414

[designsimply]

Looping back to note that I re-tested after a fix for #12448 went in and I can still see the problem happen as described here. Leaving the issue open as not a duplicate. 🙂

[talldan]

Looks like this is a duplicate of #10889