Cursor is jumping to the start of the block when autosaving

[Luxamman]

Describe the bug
It is a very annoying behavior that when writing, the cursor is jumping to the start of the block your in every time Gutenberg is auto saving. This is destroying the workflow of writing and publishing, because after the auto save you have to reposition the cursor again and again at the last point in order to be able to continue writing, or always type something so that it is not saved automatically.

I'm surprised that the bug has not been reported yet, otherwise I did not find it. After all for someone who is writing a lot, this is something like a no-go situation and to be more effective, I need to write outside Gutenberg - which should not be the way.

To Reproduce
Steps to reproduce the behavior:
Open Gutenberg, start writing a textblock and wait until it is saving.

Expected behavior
Just let the cursor stay where it is inside the actual text. Maybe something to to with reloading the block?

Screenshots

Desktop (please complete the following information):
Win10, Chrome 70/71, also Elementor Pro, Yoast, Pods and with theme Astra Pro. WordPress 5.0.1 - everything up to date at this point.

[designsimply]

I tested and was unable to see the problem happen without the extra plugins you mentioned. In my testing, I used WordPress 5.0.1 and Gutenberg 4.7.0 using Firefox 63.0.3 and Chrome 70.0.3538.110 on macOS 10.13.6. I also tested WordPress 5.0.1 without the Gutenberg plugin active. (1m8s)

It may be worth also checking Windows. If the bug cannot be reproduced there, then the next step will be to ask if it's possible for you to temporarily deactivate some of the plugins you mentioned to see if you can determine which of those may be causing the problem.

[designsimply]

Leaving Needs Testing to loop back around or get another person to help test from Windows.

[Luxamman]

After testing on WIN/MAC/Linux, I was deactivating plugins on a testserver with the same problem and now it seems, I found the plugin making problems:

"Pods - Custom Content Types and Fields" 2.7.11 from Pods Framework Team

I have some Pods in use and every time I deactivate the plugin, the cursor stays where it is.

Can anyone try and confirm that?

Thanks!

[SmartlinkR]

Can anyone try and confirm that?

I am having the same problem, but I do NOT have the plugin in question... "Pods - Custom Content Types and Fields"

I am on Wordpress 5.0.2 and I do not have the Gutenberg plugin...

[colinmcdermott]

Same issue. Can confirm am NOT running the Pods plugin.

[talldan]

Hi @SmartlinkR and @colinmcdermott - Would be great if you could both share which OS/Browser combination you're using when you see the issue?

[colinmcdermott]

Hi @talldan - sure, Chrome + Windows 10.

Confirmed latest version of Chrome - Version 71.0.3578.98 (Official Build) (64-bit)

Cheers!

[pfvks]

Having the same issue on Safari.

[colinmcdermott]

Just tested, same issue in Firefox: autosave = return to start of line.

[StudentDawid]

Same issue

[patrizz]

Same in chrome on Mac. WordPress 5.0.3 running Twenty Seventeen theme.

[colinmcdermott]

Went through the standard process of turning off all plugins enabling them one at time.

Plugin causing the issue for me was CMB2 https://wordpress.org/plugins/cmb2/ - which is required for my theme unfortunately :/

[dleigh]

It was Pods for me too. Thanks for the research @Luxamman !

[jimtrue]

Are you running 2.7.11 or 2.7.12 of Pods? It would also help in these to at least mention the developer of the plugin in question so we can be alerted to the issue. This is the first we heard about them.

[designsimply]

@jimtrue thanks for asking for a mention! I hadn't yet circled back to this issue but normally when we find a plugin or theme conflict, we try to work with people to help them get the best information possible to help them make a good bug report and then help them find a good place to post that for the plugin author. Often I will recommend posting in the plugin forum on WordPress.org. Is https://wordpress.org/support/plugin/pods a good place or is there a better spot?

[pglewis]

Now that I'm aware of it I'll track an issue for it from the Pods side. Those experiencing this issue with Pods can test the following PR and see if that clears things up: pods-framework/pods#5275

[Edit to add: be sure to cache-bust any local javascript in your browser if you're able to test]

[aduth]

Based on pods-framework/pods#5275 and looking at nearly identical code from CMB2, the problem seems to stem from calling save on an instance of TinyMCE.

for ( var i = 0; i < tinyMCE.editors.length; i++ ) tinyMCE.editors[i].save()

If I understand correctly, the intent of this is the same as what was fixed in Gutenberg with #12568, which shipped with @wordpress/[email protected] / Gutenberg 4.7 / WordPress 5.0.2 .

It does seem though that window.tinyMCE.triggerSave(); introduced with #12568 suffers from the same issue with wrongful caret placement, but the code is only reached at very specific increments, corresponding to the following logic / comment:

gutenberg/packages/edit-post/src/store/effects.js

Lines 56 to 62 in 837fda7

	// Save metaboxes on save completion, except for autosaves that are not a post preview.
	const shouldTriggerMetaboxesSave = (
	hasActiveMetaBoxes && (
	( wasSavingPost && ! isSavingPost && ! wasAutosavingPost ) ||
	( wasAutosavingPost && wasPreviewingPost && ! isPreviewingPost )
	)
	);

It's still not entirely clear to me why the caret position moves, and I've been unable to reproduce as being an issue in a minimal TinyMCE test case. This is worth investigating further.

[pglewis]

Based on pods-framework/pods#5275 and looking at nearly identical code from CMB2, the problem seems to stem from calling save on an instance of TinyMCE.

This is purely a guess on my part (I have not repro'ed the issue locally) but I have high confidence this is the problem. The history is that calling save was a workaround for #7176. I think that issue was fixed in 5.0.2, so if the workaround is causing this side effect then it should be safe for plugins that used it to remove it.

[jimtrue]

Often I will recommend posting in the plugin forum on WordPress.org. Is wordpress.org/support/plugin/pods a good place or is there a better spot?

@designsimply Yep, our forums are fine. I found out about it because it got mentioned on another WordPress.org forum and I have a 'pods' mention notification to alert me to those. Kinda hard to do that with the GitHub. We have our own GitHub as well, but I'd say once it's noticed, get it in front of the plugin developers, either in their WordPress.org forum or their GitHub if it's published and public (ours is).

This issue has been around since 12/18 but within hours of us getting mentioned on it in WordPress.org, we had escalated to our developers and @pglewis got a PR out there. Had we been escalated to immediately, this fix would've been in December ;)

[colinmcdermott]

This is now resolved in CMB2 with the latest update.

CMB2/CMB2#1202
https://wordpress.org/support/topic/gutenburg-cursor-returns-to-start-on-autosave/#post-11112862

[aduth]

I've found that this can also be reproduced in Gutenberg itself with any plugin which adds a meta box to the editor screen, specifically when the user saves the post by pressing Ctrl+S . Doing so while within a RichText (paragraph) field will reset the caret position to the start of the field.

(Example file to place in wp-content/plugins to demonstrate the issue)

[aduth]

I feel fairly confident that the issue with caret moving unexpectedly in paragraph blocks will have been totally resolved with recent refactoring to the RichText component, specifically in #13697 (cc @iseulde). This would have landed in Gutenberg 5.1, and would become part of the next WordPress 5.2 release.

There may still be a lingering issue for meta boxes which include their own TinyMCE editors, like the example provided in #7176 (comment) (related: #12568). It should be tested to see whether the caret moves unexpected after saving the post in this scenario, though it may be difficult to test using the instructions at #12942 (comment) if TinyMCE implements its own explicit handling for Ctrl+S.

[youknowriad]

We haven't seen any recent reports of this. So i'm going to close this, if you manage to reproduce it please consider opening a new issue with as many details as you can.