Pasting text into columns isn't showing up on frontend

[mapk]

Describe the bug
I'm trying to paste test into the Column block, but that text isn't showing on the frontend. It only shows up if I make a change to the color, size, or another attribute first, then it shows.

To reproduce
Steps to reproduce the behavior:

1. Add Columns block.
2. Copy and paste text from another website into each of the columns.
3. Save the document and preview it.
4. Observe that the text isn't showing on the frontend.

Expected behavior
I expect that the text shows without having to change any attributes of it. In the screencast below, I've already copied the text in the Columns block. I've made an attribute change to the text in the first columns making a line bold. But the other two columns I haven't touched. When I check the preview, the two columns of text don't show.

Screenshots

Desktop (please complete the following information):

• OSX
• Firefox 68.0
• Gutenberg 6.1

[draganescu]

I think this is a problem with all Inner Blocks. So far found the behaviour in both columns and the group block and it doesn't matter in what kind of block we paste: heading, list or paragraph.

This also happens if you add a paragraph and paste a copied image in it: the block is converted to image but after save and refresh it's gone.

[noisysocks]

When the text is pasted, the REPLACE_BLOCKS action swaps out the inner block for a new block. My guess is that this doesn't update the store in a way that invalidates the cached getBlocks selector:

gutenberg/packages/block-editor/src/store/selectors.js

Lines 176 to 188 in 643412c

	export const getBlocks = createSelector(
	( state, rootClientId ) => {
	return map(
	getBlockOrder( state, rootClientId ),
	( clientId ) => getBlock( state, clientId )
	);
	},
	( state ) => [
	state.blocks.byClientId,
	state.blocks.order,
	state.blocks.attributes,
	]
	);

[talldan]

I have a theory, but it needs more testing to verify it. The issue might be the caching of getBlock, which getBlocks calls through to.

gutenberg/packages/block-editor/src/store/selectors.js

Lines 123 to 144 in 643412c

	export const getBlock = createSelector(
	( state, clientId ) => {
	const block = state.blocks.byClientId[ clientId ];
	if ( ! block ) {
	return null;
	}
	return {
	...block,
	attributes: getBlockAttributes( state, clientId ),
	innerBlocks: getBlocks( state, clientId ),
	};
	},
	( state, clientId ) => [
	// Normally, we'd have both `getBlockAttributes` dependancies and
	// `getBlocks` (children) dependancies here but for performance reasons
	// we use a denormalized cache key computed in the reducer that takes both
	// the attributes and inner blocks into account. The value of the cache key
	// is being changed whenever one of these dependencies is out of date.
	state.blocks.cache[ clientId ],
	]
	);

I notice that it only has state.blocks.cache[ clientId ], as the data that invalidates it.

This cache looks like it is updated when the replaceBlocks action is triggered, but only for the replaced block itself (the leaf inner block that the content has been pasted into) and the block that replaces it:

gutenberg/packages/block-editor/src/store/reducer.js

Lines 266 to 273 in 643412c

	case 'REPLACE_BLOCKS_AUGMENTED_WITH_CHILDREN':
	newState.cache = {
	...omit( newState.cache, action.replacedClientIds ),
	...fillKeysWithEmptyObject(
	getBlocksWithParentsClientIds( keys( flattenBlocks( action.blocks ) ) ),
	),
	};
	break;

The issue might be that when getBlock is called for the parent column block, its cache entry hasn't been invalidated, so it doesn't bother recursing down to fetch the replaced inner blocks. The selector still returns the column as having the old inner block

Contrast this to inserting a new block for an inner block and it looks like the rootClientId is added to the list of blocks that should be invalidated, which means it doesn't happen there:

gutenberg/packages/block-editor/src/store/reducer.js

Lines 244 to 256 in 643412c

	case 'INSERT_BLOCKS': {
	const updatedBlockUids = keys( flattenBlocks( action.blocks ) );
	if ( action.rootClientId ) {
	updatedBlockUids.push( action.rootClientId );
	}
	newState.cache = {
	...newState.cache,
	...fillKeysWithEmptyObject(
	getBlocksWithParentsClientIds( updatedBlockUids ),
	),
	};
	break;
	}

[talldan]

Looks like it's related to the incorrect clientId being passed into getBlocksWithParentsClientIds. #16717 should fix it.