Cursor jumps to end in TextControl with attribute source 'meta' after each keystroke

[estebanwaseaten]

Describe the bug
In WP 5.2, if a TextControl component is connected to an attribute with source 'meta', whenever I try to type something in the middle of the already typed text, the cursor jumps to the end after each keystroke.
If I comment out the source and meta attributes (such that the data is stored in the html block comment), this behaviour changes: now typing in the middle of already present text works fine.
Storage of the metadata is working fine in both cases.

To reproduce

1. copy and paste the code from the WP example https://developer.wordpress.org/block-editor/tutorials/metabox/meta-block-1-intro/ into your themes code.
2. create one of these meta blocks (called "Meta Block") in the Gutenberg editor.
3. type something into the TextControl.
4. Move your cursor somewhere in the middle and continue typing
   observed behaviour: after the first keystroke the cursor jumps to the end of the content.

Expected behavior
the cursor stays behind the most recently typed character

Desktop (please complete the following information):

• OS: Windows 7

• Browser: Firefox

• Version: 60.6.3esr (32-bit)

• OS: OS X

• Browser: Safari

• Version: 12.1.1

Additional context
I am using the built in latest version of Gutenberg as of the time of this post.
I have noticed that the edit() function of the block is called twice for each keystroke in the buggy case (source: 'meta'). If a different source is selected this does not seem to happen.

Thanks everybody in advance!

[estebanwaseaten]

...same behaviour in wp.editor.PlainText component

[estebanwaseaten]

...this also seems to happen for an 'input' Element with source 'meta'

[aduth]

Can you clarify: Do you know if this had worked correctly in previous versions of WordPress?

[aduth]

In initial debugging, the cause seems to be that when a meta attribute value is updated, the block's edit function renders twice. The first time uses the old (inaccurate) value, the second with the value now reflecting the updated meta. It's that intermediate render which is causing the issue, since React is not able to reconcile where the text caret should reside.

Approximated minimal reproducing example: https://codepen.io/aduth/pen/XwVeWp

It may be specifics of timing of meta updates.

If a regression, possible candidates which come to mind for having caused it include:

• Try a generic block editor module #13088
• Update the block component to use react hooks instead #14985

[estebanwaseaten]

Can you clarify: Do you know if this had worked correctly in previous versions of WordPress?

Unfortunately I only started porting old metaboxes to meta-blocks quite recently, so I am not sure if this behaviour was present in earlier versions.

(Indeed I have also observed that edit() is called twice, which does not happen if there is no connection to 'meta')

[aduth]

If a regression, possible candidates which come to mind for having caused it include:

• Try a generic block editor module #13088
• Update the block component to use react hooks instead #14985

In further testing, I can still reproduce the issue even before both of these commits. I am beginning to suspect that this issue, while certainly a valid bug, may not necessarily be a regression of WordPress 5.2 as originally suspected.

[aduth]

In further testing, I can still reproduce the issue even before both of these commits. I am beginning to suspect that this issue, while certainly a valid bug, may not necessarily be a regression of WordPress 5.2 as originally suspected.

Correction: I was testing the wrong thing. Upon closer examination, I've confirmed this is a regression of 0c4f457 (#13088).

[aduth]

Fix proposed at #15781