Gutenberg: Firefox: RichText: invisible trailing <br> tags

[maddisondesigns]

Issue Overview

I have a page with a number of different Heading blocks. Some of the blocks display fine on the front-end (e.g. <h3>Some text</h3>) and other headings have an extra <br> tag included (e.g. <h3>Some text<br></h3>)

These couple of headings are displaying fine

This heading has the extra <br> tag

When you look at the block with the extra tag, in the Visual Editor, it appears fine. If I click in the block and try to remove any extra (invisible) characters from the end, I can't.

If I switch to the Code Editor, I can see the extra <br> tag which I never put in and I can't remove (using the Visual Editor).

Steps to Reproduce (for bugs)

1. Insert multiple headings and update page
2. View markup on front-end and see if any include extraneous tags

Expected Behavior

Headers shouldn't randomly include <br> tags

Current Behavior

Headers randomly include extra markup that you can't get rid of

_Gutenberg 2.5.0
Firefox Quantum 59.0.2 (64-bit)
WP 4.9.4_

[ZebulanStanphill]

Thanks for reporting this... I experienced this issue back in Gutenberg 2.3 while writing a post, but I forgot to create an issue about it.

I did some quick testing just now in Gutenberg 2.5, and it looks like if you press Shift+Enter to add a new line to a Heading block (and not create a new block), and then press Backspace to remove that new line, a <br/> tag is left behind and can be seen when you edit the block as HTML.

EDIT: I also did a quick test in Gutenberg 0.1, and it looks like the above-described behavior happens in that version as well. So this appears to be an issue that has always existed with the Header block.

[maddisondesigns]

@SuperGeniusZeb I'm getting <br> tags without even pressing Shift+Enter.

[danielbachhuber]

I'm able to reproduce this without pressing Shift+Enter:

[danielbachhuber]

My hunch is that this is an artifact of the Rich Text component, as I don't see anything in the heading block that relates to managing <br> tags.

[yuanworks]

As @danielbachhuber suspects, it's not related to the heading as this also happens on regular paragraph blocks. However, it doesn't happen when creating a Classic block.

[brandonpayton]

I am not able to reproduce this on master. Can anyone else on this ticket still reproduce it?

[designsimply]

Tested using WordPress 4.9.8 and Gutenberg 4.1.1 using Firefox 62.0.3 on macOS 10.13.6 with the steps provided and I don't see any extra <br> tags added when I check the published post on the front end. (screenshot)

1. Insert multiple headings and update page
2. View markup on front-end and see if any include extraneous tags

Closing since the last two reports on this thread note that the problem cannot be reproduced in later versions. If you're still having trouble and can think of something we may be missing in our testing steps, please comment and we'll re-open!

[maxxwv]

I'm seeing this behavior in WP 4.9.8 and Gutenberg 4.1.1. All I do is update the content in a RichText component and the <br> tag is appended to the value.

[danielbachhuber]

All I do is update the content in a RichText component and the <br> tag is appended to the value.

I'm still seeing this too (FF 63.0.3).

This is with a custom block using the RichText component:

[mkaz]

Possibly related to #11037

@danielbachhuber is there a way for me to test with your custom block? I can't seem to duplicate this or the issue in #11037 - running latest Gutenberg on 4.9.8

We've seen this issue occur with conflicts with the wpautop priority change and plugins that filter the_content, which should be fixed in this core ticket: https://core.trac.wordpress.org/changeset/43879

[danielbachhuber]

@mkaz Yes, I'll see if I can put together a custom block that reproduces the issue. This is against latest Gutenberg running 4.9.8

[danielbachhuber]

@mkaz This snippet reproduces regularly for me:

var registerBlockType = wp.blocks.registerBlockType;
var RichText = wp.editor.RichText;
var __ = wp.i18n.__;


registerBlockType('daniel/test-block', {
    title: __('Daniel Test Block'),
    icon: '',
    category: 'common',
    attributes: {
        title: {
            type: 'string',
            source: 'html',
            selector: 'h3.title'
        }
    },
    supports: {
        className: false
    },
    edit: function edit(props) {
        var attributes = props.attributes,
            setAttributes = props.setAttributes;
        var title = attributes.title;

        return React.createElement(
            'div',
            { className: 'medium-6 panel columns' },
            React.createElement(RichText, {
                tagName: 'h3',
                value: title,
                placeholder: __('Enter title…'),
                formattingControls: [],
                onChange: function onChange(value) {
                    console.log( value );
                    setAttributes({
                        title: value
                    });
                }
            })
        );
    },
    save: function save(props) {
        var title = props.attributes.title;

        return React.createElement(
            'div',
            { className: 'medium-6 panel columns' },
            React.createElement(
                'h3',
                { className: 'title' },
                title
            )
        );
    }
});

Notice the console.log() on the onChange callback. Here's a GIF of the behavior:

Notably, the <br> appears as soon as a space is entered. Here's a second test case that communicates this behavior:

[danielbachhuber]

Also worth noting: the <br> doesn't display in the editor until you've saved and refreshed the Post.

[lkraav]

Oh nice, mine is probably a duplicate of this, too https://github.com/WordPress/gutenberg/issues/11365

[danielbachhuber]

@lkraav Yes, likely.

Also worth noting I've implemented some trimBrTag() that I run on the save callback:

export const trimBrTag = ( value ) => {
    return value.replace(/<br>$/, '');
};

However, this has the undesirable impact that the first space you enter into the RichText field mysteriously disappears.

By moving the trimBrTag() call to the _block_ save callback, I was able to trim the <br> without experiencing the space issue.

[maxxwv]

@danielbachhuber - another issue is that'll strip out _all_ <br> tags - even those that are intentional, won't it?

[danielbachhuber]

@maxxwv No, my regex only trims the last <br> on the value.

[maxxwv]

@danielbachhuber - Ah. RegEx is not my strong suit - thanks!

[mkaz]

@danielbachhuber - Thanks for the sample block, I'm able to reproduce.

Digging in to figure out what is going on and why.

[mkaz]

So, it looks like the sample block is getting the entered value with the HTML markup converted but then setting it in the save as a plain text string.

It works if I change the save method to set as HTML, instead of text:

save: function save(props) {
    var title = props.attributes.title;
    return React.createElement(
        'div',
        { className: 'medium-6 panel columns' },
        React.createElement(
            'h3',
            {
                className: 'title',
                dangerouslySetInnerHTML: { __html: title }
            },
        )
    );
}

Still looking to see if there is a different way to do it, by getting the entered content without the markup and then have it added on only display, though then we'll start getting into autop territory. Thar be dragons!

[danielbachhuber]

@mkaz It's worth noting that this behavior seems specific to Firefox. The sample block works as expected (i.e. doesn't introduce <br> tags) in Chrome. So I feel like the underlying problem is some browser implementation detail with the RichText component.

Notably, per your example, props.attributes.title shouldn't have a <br> in its string by the time it hits the save callback.

[mkaz]

Sorry, clicked the wrong button. I see the same issue in Chrome for me ( v70 on macOS)

[mtias]

Moving this to 5.0 if it can be addressed.

[ellatrix]

Thanks for the detailed steps @danielbachhuber. I'll work on a fix right now.

[ellatrix]

Firefox inserts this line break element to ensure the spaces you type at the end of an editable element stay visible. Normally in HTML, spaces, newlines and tabs are used to format HTML. In between words they are reduced to one visible space. Any leading spaces or trailing spaces are simply omitted. Browser work around this problems in different ways. Chrome inserts non breaking spaces, which it (most of the time) removes again when it no longer needs them. This is an equally terrible way of fixing the problem, because when Chrome doesn't remove the non breaking spaces, they mess up the user's content. Firefox fixes the issue with a trailing line break, and doesn't remove it when the line no longer ends with a space, so it gets included in the content as well. We cannot simply remove it because RichText is a controlled component. Any changes to the value flow back into the live DOM. Removing the line break would break Firefox ability to display trailing space characters when typing.

I think the best way to deal with this is to come up with a way to fix this in all browsers the same way and build it into RichText. That's what I'm attempting right now.

[ellatrix]

Since there should be no visual difference on the front-end either, I'm going to move this issue to 5.0.1.

[danielbachhuber]

Since there should be no visual difference on the front-end either, I'm going to move this issue to 5.0.1.

@iseulde Just to be clear, there is a visual difference on the frontend: the <br> ends up HTML encoded and ends up in the display of the element.

[ellatrix]

@danielbachhuber Is that with core blocks? I can't reproduce that. Note that if you use RichText in a plugin, you need to save the content with RichText.Content.

[danielbachhuber]

Is that with core blocks?

@iseulde It's with this code snippet: https://github.com/WordPress/gutenberg/issues/5872#issuecomment-440050606

Note that if you use RichText in a plugin, you need to save the content with RichText.Content.

I don't understand. Can you clarify? My current implementation is this:

React.createElement(RichText, {
    tagName: 'h3',
    value: title,
    placeholder: __('Enter title…'),
    formattingControls: [],
    onChange: function onChange(value) {
        console.log( value );
        setAttributes({
            title: value
        });
    }
})

[ellatrix]

@danielbachhuber What happens if you make some text italic (cmd+i)? Will that also de encoded? I think you need to same the content with RichText.Content in the save function. See https://wordpress.org/gutenberg/handbook/block-api/rich-text-api/#richtext-content.

[danielbachhuber]

@iseulde Oh, huh. Maybe developer error then. I'll look into this next week.

[ellatrix]

The issue with the trailing line break is valid, but it's not a blocker. It shouldn't display on the front end if the rich text content is saved correctly. There will just be a trailing line break in the HTML, which isn't that bad.

[ellatrix]

12166 should fix this issue.

[maxxwv]

I am still seeing this as of updating to WP5.0-RC2-43958. Relevant code:

const { registerBlockType } = wp.blocks;
const {
    MediaUpload,
    RichText,
} = wp.editor;
const {
    Button,
    TextControl
} = wp.components;

registerBlockType(
    'aw/floor-plan-in-content', {
        title: __('Floor Plan'),
        icon: 'index-card',
        category: 'common',
        attributes:{
            title: {
                type: 'string',
                source: 'text',
                selector: '.fp_header'
            },
//      ...
        },
        edit: props => {
            const {
//          ...
                title,
//          ...
            } = props;
            return(
                <div className = { props.className }>
                    <RichText
                        tagName = "h2"
                        className = "fp_header widefat"
                        placeholder = {__("Floor Plan name")}
                        keepPlaceholderOnFocus={ true }
                        value = { title }
                        onChange= { onChangeTitle }
                        multiline = { false }
                        formattingControls = { [] }
                    />
//              ...
                </div>
            )
        },
        save: props => {
            const {
                attributes: {
                    title,
//              ...
                }
            } = props;

            return (
                <div className={"floorplan-display" }>
//              ...
                    <RichText.Content
                        tagName = "h2"
                        className = "fp_header"
                        value = { title }
                    />
//              ...
                </div>
            )
        }
    }
);

Console error:

Block validation: Expected token of type 'EndTag' ({ tagName: "h2", type: "EndTag", <prototype> }), saw instead 'Starting' ({ attributes: Array [], selfClosing: false, tagName: "br", type: "StartTag", <prototype> })

Expected:

<div class="wp-block-aw-floor-plan-in-content floorplan-display"> [...] <h2 class="fp_header">Testing again</h2><div> [...] </div></div>

Actual:

<div class="wp-block-aw-floor-plan-in-content floorplan-display"> [...] <h2 class="fp_header">Testing again<br></h2><div> [...] </div></div>

Note the <br> inside my <h1> tag on output. This is breaking validation and causing my block to error on every page (re)load.

[ZebulanStanphill]

I am still getting <br> tags in the editor when I use the Edit as HTML option in Gutenberg 4.6.1. I'm not getting any on the front-end, though.

[youknowriad]

This PR is not included in a release yet.