Editor: Fix regression introduced in CopyHandler

[gziolo]

Description

Fixes #12506.

Regression introduced in #11851.

Reported by @afercia:

• go in any post
• select some text in a block editable area, either with mouse or keyboard doesn't matter, and try to paste it in another block or in an external editor
• nothing happens (if you have previous content in your clipboard, that will be pasted)
• try to cut text: nothing happens
• try also in the post title: same as above
• try also with an embed, for example a vimeo embed: paste https://vimeo.com/22439234 then edit it e.g. remove a few numbers, copy, paste it: the previous full URL get pasted
• try to cut the vimeo URL: nothing happens
• try even to select some text in the editor UI, outside of any block, for example the paragraph block description:

• copy and paste it: same as above
• switch to Code Editor mode: everything works normally

Basically any basic Copy / Cut operation in the Visual Editor is currently broken.

Initially, I tried to fix it by returning the information whether copy handler override was triggered but it is not possible to return a value from the dispatch handler exposed by withDispatch. It seems like a design decision?

I ended up with moving event handling to the handlers created in withDispatch which removes some lines of code. I know that @aduth wanted to avoid that in #11851 as discussed in #11851 (comment). An alternative would be to move event handling to the callback. I'm happy to iterate if you think it'd be cleaner.

How has this been tested?

• go to any post
• select some text in a block editable area, either with mouse or keyboard doesn't matter, and try to paste it in another block or in an external editor
• try to cut text
• try also in the post title
• try also with an embed, for example a vimeo embed: paste https://vimeo.com/22439234 then edit it e.g. remove a few numbers, copy, paste it: the previous full URL get pasted
• try to cut the vimeo URL
• try even to select some text in the editor UI, outside of any block, for example the paragraph block description:

• copy and paste it
• switch to Code Editor mode

All of that should basically work.

[gziolo]

Sadly, it looks like it isn't possible to add e2e tests which would prevent this regression in the future. Such tests would only work when puppeteer operates with a real browser. It won't work in the headless mode which is the most expected way of running those tests. A related issue where this limiation is explained #2147.

[aduth]

To be clear, the bug is that we'd call event.preventDefault in cases where we weren't handling block copying behaviors?

[aduth]

Another implementation which might be preferable is that the event handlers are bound and unbound in response to the change in condition applying. i.e. we don't bind on mount, but rather when the selectedBlockClientIds.length > 0 && ( hasMultiSelection() || ! documentHasSelection() ).

For the purposes of resolving the regression, I'm fine with the general approach here. I think the main blocker for me would be the reference of onCopy passed to addEventListener / removeEventListener needing a stronger guarantee to be the same.

[aduth]

I should have noted this in the previous pull request: But why do we do work here on selecting data, rather than within the callbacks? I don't think we should have any function calls in the upper wrapper aside from dispatch or select.

[gziolo]

It is evaluated at the time when a method is called so it doesn't matter from the technical standpoint. There will be some code duplication otherwise. I can move it to methods if you prefer to have it implemented this way.

[aduth]

It's evaluated when the component mounts as well. I'm fine with (in-fact, prefer) the code duplication.

[gziolo]

Yep, updated to be placed inside functions, not that much code added to be honest 👍

[aduth]

I don't trust this here. I should have noted it in the prior pull request too. Can we just have onCopy declared as a proper function in the scope, and call upon that here?

function onCopy() {}

return {
	onCopy,
	onCut() {
		onCopy();

		// ...
	},
};

[gziolo]

Yes, I wasn't sure about it either. It works but might break in the future 👍

[aduth]

I don't really trust that the reference of onCopy prop passed in componentDidMount is the same as the one in componentWillUnmount. In practice, it probably is, based on the current implementation of withDispatch. But I don't think it's a guarantee any component should rely on that a prop reference from mount is the same as in unmount.

In other words, an instance's onCopy = ( event ) => this.props.onCopy( event ); , while seemingly redundant, seems a much safer reference to rely upon.

[gziolo]

Yes, in retrospect I think you are right, if there are 2 instances of this component they would reference the same function with this implementation. I will fix it.

[gziolo]

To be clear, the bug is that we'd call event.preventDefault in cases where we weren't handling block copying behaviors?

Yes, correct 👍

[aduth]

Looks good 👍

[aduth]

Just to confirm: We're relying on the event.preventDefault() to have already occurred in onCopy?

[gziolo]

Yes, this is what we had before the refactoring, see: https://github.com/WordPress/gutenberg/blob/b2e5ae79fc74f6730e1ded1332e66e6ee732e67d/packages/editor/src/components/copy-handler/index.js