Pasting should bring you to end of content, not beginning

[melchoyce]

When you paste a couple paragraphs into Gutenberg, your cursor remains at the beginning of the first paragraph you pasted. I expect it to be at the end of the last paragraph pasted.

Example gif:

Related issue:
#6821

[karmatosed]

Good catch, totally agree it's sensible you'd go to the last place you pasted from.

[Kluny]

I'd like to work on this if no one else is.

[karmatosed]

That would be awesome @Kluny - thanks!

[designsimply]

Noting that a similar behavior was reported for inline boundaries at #8387 where pasted content at the end of bold text land the content and caret before the inline boundary instead of at the end where the cursor was at the time of pasting. (26s)

[noisysocks]

Noticed this during some user testing—it really interrupted the user's flow. Adding this to the Editor milestone as I think it's an important rough edge to smooth off.

[davidwolfpaw]

I came in to leave this issue, but instead I can second it here.

I submitted a similar issue for the Boostnote editor a few months ago and a fix was created there. Perhaps it could provide a starting point for a solution?

BoostIO/BoostNote-Legacy#1950

[earnjam]

Relabeling to bug. I'm not aware of any text field in any software that places the cursor at the beginning of pasted content.

[ellatrix]

This is something that could be considered when revising the onSplit prop in #10761.

[chrisvanpatten]

It'd be so awesome to see this resolved. I do a lot of copy/paste and this really throws off my flow.

[davewhitley]

Another flow I don't think has been mentioned:

• Write some text
• Paste some text at the end of the paragraph
• Undo with command + z
• Cursor unexpectedly jumps to the beginning

[aduth]

Considering technical implementation, there are a handful of ways which pasted content is handled while within a RichText (paragraph) field. Most relevant to the issue is what happens here:

gutenberg/packages/editor/src/components/rich-text/index.js

Lines 290 to 321 in e969954

	const shouldReplace = this.props.onReplace && this.isEmpty();
	let mode = 'INLINE';
	if ( shouldReplace ) {
	mode = 'BLOCKS';
	} else if ( this.onSplit ) {
	mode = 'AUTO';
	}
	const content = pasteHandler( {
	HTML: html,
	plainText,
	mode,
	tagName: this.props.tagName,
	canUserUseUnfilteredHTML: this.props.canUserUseUnfilteredHTML,
	} );
	if ( typeof content === 'string' ) {
	const recordToInsert = create( { html: content } );
	this.onChange( insert( record, recordToInsert ) );
	} else if ( this.onSplit ) {
	if ( ! content.length ) {
	return;
	}
	if ( shouldReplace ) {
	this.props.onReplace( content );
	} else {
	this.splitContent( content, { paste: true } );
	}
	}

There are three routes this can take:

• If the pasted content can be considered as plaintext (single paragraph text), and the current block is not empty, it's concatenated to the current paragraph. The caret is placed correctly.
• If the block is not empty, but the content is still plaintext, the paragraph is replaced with a new paragraph. The caret wrongly resets to the beginning of the new paragraph.
• If the pasted content will result in multiple blocks (multiple paragraphs of text), it will replace if the current block is empty, or split otherwise. The result is effectively the same, the new blocks are added. The caret is wrongly placed at the beginning of the first of the new paragraphs.

A first thought occurs to me: In the second point, why do we replace with a new paragraph? We could just inherit the same behavior as in the first point, and the caret would be placed correctly.

For the last point, whether it's a replacement or a split (which operates by "inserting" blocks), we should consider how to leverage the existing handling for an initialPosition value of block selections to move the caret to the end of the new set of blocks:

gutenberg/packages/editor/src/components/block-list/block.js

Lines 147 to 163 in 14374e5

	// If reversed (e.g. merge via backspace), use the last in the set of
	// tabbables.
	const isReverse = -1 === initialPosition;
	const target = ( isReverse ? last : first )( textInputs );
	if ( ! target ) {
	this.wrapperNode.focus();
	return;
	}
	target.focus();
	// In reverse case, need to explicitly place caret position.
	if ( isReverse ) {
	placeCaretAtHorizontalEdge( target, true );
	placeCaretAtVerticalEdge( target, true );
	}

The issue here is whether this is safe to infer:

• Should it be limited to only when the replacement occurs where the replaced set had included the currently-selected block?
• Should it be based on the value of the existing updateSelection parameter for insertBlocks?
• In general, ensuring that we're not overly biased about assuming these actions are triggered as the result of any specific user interactions. It is entirely possible for block inserts and replacements to occur programmatically, including by plugins.

Depending on the answer to these, I could see changes being made either as an effect handler of block replacement and/or in the block selection reducer handling of block insertion.

[ellatrix]

Reopening as after #13294 the last block will now be selected, but ideally the caret should be put at the end as well.

[gziolo]

Reported also in #15166 by @QiShaoXuan:

When I copy a piece of text into the editor, the cursor always precedes the text, I think it need appear at the end of text.
You can try it in gutenberg website.

@maurisrx:

Yes, I can also confirm that. Every time I copy paste text to new paragraph block, the cursor doesn't automatically move to the end of the text but it stays at the beginning of the text.

@GlennMartin1 :

Same here. Using Chrome on Windows.

[ehti]

In editor triage today, a related issue came up but we noticed this odd behavior as well.

[adamziel]

Proposed a solution in #21755

[ellatrix]

This was fixed in #21755.