Widgets: HTML block is formatted using `autop` and has its attributes removed

[sabernhardt]

Description

In the new widget editor, Custom HTML widget blocks can get (additional) paragraph and line break tags.

Originally reported by jim5471 on Trac #53778

Step-by-step reproduction instructions

1. Go to Dashboard > Appearance > Widgets.
2. Insert a Custom HTML Block into the footer and insert this code:

<div><p>some text</p>
<a href="http://www.test.com">link text</a>
</div>
<svg height="90" width="200">
  <text x="10" y="20" style="fill:red;">Several lines:
    <tspan x="10" y="45">First line.</tspan>
    <tspan x="10" y="70">Second line.</tspan>
  </text>
</svg> 

3. Update and check it appears on the webpage and is correct.
4. Go back to Dashboard and then back to Appearance > Widgets.
5. Observe the Custom HTML code has additional paragraph and line break tags.

Firefox:

<div>
<p>some text</p>
<p><a href="http://www.test.com">link text</a>
</p></div>
<p><svg height="90" width="200"><br></br>
  <text x="10" y="20" style="fill:red;">Several lines:<br></br>
    <tspan x="10" y="45">First line.</tspan><br></br>
    <tspan x="10" y="70">Second line.</tspan><br></br>
  </text><br></br>
</svg></p>

Edge/Chrome:

<div>
<p>some text</p>
<p><a href="http://www.test.com">link text</a>
</p>
</div>
<p><svg height="90" width="200"></svg><br>
  <text x="10" y="20" style="fill:red;">Several lines:<br>
    <tspan x="10" y="45">First line.</tspan><br>
    <tspan x="10" y="70">Second line.</tspan><br>
  </text>
</p>

6. Change another widget and update.
7. Go back to Dashboard and then back to Appearance > Widgets.
8. In Chrome and Edge, the code stays the same as in step 5. In Firefox, though, the Custom HTML code changes again:

<div>
<p>some text</p>
<p><a href="http://www.test.com">link text</a>
</p>
</div>
<p><svg height="90" width="200"><br></br></svg><br><br>
  <text x="10" y="20" style="fill:red;">Several lines:<br><br><br>
    <tspan x="10" y="45">First line.</tspan><br><br><br>
    <tspan x="10" y="70">Second line.</tspan><br><br><br>
  </text><br><br><br>
</p>

Expected Behavior

The Custom HTML block widget contents should remain exactly as entered.

Current Behavior

The block widget has autop formatting (from @wordpress/autop).

WordPress Information

WordPress 5.8
Twenty Twenty-One theme
no plugins
local installation with PHP 7.3.21

Gutenberg Information

Gutenberg not activated

What browsers are you seeing the problem on?

Firefox, Chrome, Microsoft Edge

Device Information

Desktop browsers:
Google Chrome 92.0.4515.107 (64-bit) - Incognito mode
Mozilla Firefox 90.0.2 (64-bit) - Private window
Microsoft Edge Version 92.0.902.62 (64-bit)

Operating System Information

Windows 10 Home 20H2 19042.1110

Is there an existing issue for this?

• I have searched the existing issues

Have you tried deactivating all plugins except Gutenberg?

• I have tested with all plugins deactivated.

Have you tried replicating the bug using a default theme e.g. Twenty Twenty?

• I have tested with a default theme.

[talldan]

I haven't had a chance to test this yet, but I wonder if it's related to #33164.

There's this case where autop is applied, but I don't think it was supposed to happen for something intentionally inserted as the HTML block:

gutenberg/packages/blocks/src/api/parser.js

Lines 499 to 504 in a3445cc

	// Fallback content may be upgraded from classic content expecting implicit
	// automatic paragraphs, so preserve them. Assumes wpautop is idempotent,
	// meaning there are no negative consequences to repeated autop calls.
	if ( name === freeformContentFallbackBlock ) {
	innerHTML = autop( innerHTML ).trim();
	}

It might be an unexpected side-effect.

[azaozz]

Yes, the handling of freeformContentFallbackBlock is the cause, thanks @talldan. Happens because on the widgets settings screens the fallback block is set to Custom HTML.

The assumptions there (from 4 years ago) are somewhat incorrect. Autop might be needed only when editing posts, not in any other case. The removal of paragraph tags (the pre_wpautop part) was applied only on the content from the old post editor.

Seems the fix would be to move the decision outside of the parser, perhaps pass autop = true|false in the settings. Then autop can be applied only when editing posts. Alternatively (to keep this hard-coded) autop should be applied only on the new Edit Post screen or perhaps only when the Classic block is the fallback (the default).

Another bug that needs fixing (imho) is to apply autop only on undelimited content, i.e. when actually using the freeformContentFallbackBlock. Currently autop is applied to all blocks that are set as fallback, regardless of whether they are actually used as fallback.

Looking at usage (https://wpdirectory.net/search/01FC72F5R2CC5Q15W9M1GYHEG2), there are only two plugins that have setFreeformContentHandlerName but seems it is in their dependencies, not used to change the default block. Seems this is virtually unused feature.

[azaozz]

Been looking at this for a while, see several bugs and inconsistencies with how FreeformContentHandler is used. For this particular case the most straightforward fix seems to be to run the FreeformContent through wpautop only when editing a post as pre_wpautop was applied in the old editor only when saving posts.

[mcsf]

For this particular case the most straightforward fix seems to be to run the FreeformContent through wpautop only when editing a post as pre_wpautop was applied in the old editor only when saving posts.

I'll defer to others w.r.t. how many editing contexts should be affected by this fix, but I too think that the solution is to disable autop at least in the Widget editor. Doing the same in nascent block editors, like Nav and Site, might be a step towards phasing out autop (perhaps around 2050 AD).

[draganescu]

So I've been through the conversation here and in #34023 and I don't have a clear picture how could this be fixed. I understand that we need:

1. a way to disable wpautop for some editors (widgets, nav, site)
2. a way to disable wpautop for some freeform handlers

Can we filter parser "settings" and then pass a setting to not run wpautop or does it have to be more complicated? Sorry for asking if the answer is here :D but I couldn't grasp the summary from the conversations.

[talldan]

There's a discussion in slack that the core html block is also not saving its comment delimiters in the widgets editor. (https://wordpress.slack.com/archives/C01D71823PB/p1632988086021300)

I think it's likely caused by the same issue, since this is the same behavior the classic block has in the post editor.

I'm not fully up-to-date on the entire story. Could a solution involve passing some more information to setFreeformContentHandler? (https://github.com/WordPress/gutenberg/blob/trunk/packages/edit-widgets/src/index.js#L103)

e.g. setFreeformContentHandler( 'core/html', { autop: false, commentDelimiters: true } );