New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Cursor is jumping to the start of the block when autosaving #12942

Open
Luxamman opened this Issue Dec 17, 2018 · 21 comments

Comments

Projects
None yet
@Luxamman
Copy link

Luxamman commented Dec 17, 2018

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
autosavebug

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.

@Luxamman Luxamman changed the title Cursor is jumping to the start of block when autosave Cursor is jumping to the start of block when autosaving Dec 17, 2018

@Luxamman Luxamman changed the title Cursor is jumping to the start of block when autosaving Cursor is jumping to the start of the block when autosaving Dec 17, 2018

@designsimply

This comment has been minimized.

Copy link
Contributor

designsimply commented Dec 17, 2018

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

This comment has been minimized.

Copy link
Contributor

designsimply commented Dec 17, 2018

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

@Luxamman

This comment has been minimized.

Copy link
Author

Luxamman commented Dec 18, 2018

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

This comment has been minimized.

Copy link

SmartlinkR commented Dec 28, 2018

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

This comment has been minimized.

Copy link

colinmcdermott commented Dec 29, 2018

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

@talldan

This comment has been minimized.

Copy link
Contributor

talldan commented Jan 7, 2019

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

This comment has been minimized.

Copy link

colinmcdermott commented Jan 7, 2019

Hi @talldan - sure, Chrome + Windows 10.

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

Cheers!

@pfvks

This comment has been minimized.

Copy link

pfvks commented Jan 8, 2019

Having the same issue on Safari.

@colinmcdermott

This comment has been minimized.

Copy link

colinmcdermott commented Jan 8, 2019

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

@StudentDawid

This comment has been minimized.

Copy link

StudentDawid commented Jan 8, 2019

Same issue

@patrizz

This comment has been minimized.

Copy link

patrizz commented Jan 12, 2019

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

@colinmcdermott

This comment has been minimized.

Copy link

colinmcdermott commented Jan 13, 2019

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

This comment has been minimized.

Copy link

dleigh commented Jan 18, 2019

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

@jimtrue

This comment has been minimized.

Copy link

jimtrue commented Jan 18, 2019

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

This comment has been minimized.

Copy link
Contributor

designsimply commented Jan 18, 2019

@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

This comment has been minimized.

Copy link
Contributor

pglewis commented Jan 18, 2019

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

This comment has been minimized.

Copy link
Member

aduth commented Jan 18, 2019

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/edit-post@3.1.5 / 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:

// 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

This comment has been minimized.

Copy link
Contributor

pglewis commented Jan 18, 2019

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

This comment has been minimized.

Copy link

jimtrue commented Jan 19, 2019

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 comment has been minimized.

Copy link

colinmcdermott commented Jan 21, 2019

@aduth

This comment has been minimized.

Copy link
Member

aduth commented Jan 21, 2019

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)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment