Skip to content
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

Closed
Luxamman opened this issue Dec 17, 2018 · 23 comments
Closed

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

Luxamman opened this issue Dec 17, 2018 · 23 comments

Comments

@Luxamman
Copy link

@Luxamman 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
Copy link
Member

@designsimply 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
Copy link
Member

@designsimply designsimply commented Dec 17, 2018

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

@Luxamman
Copy link
Author

@Luxamman 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
Copy link

@SmartlinkR 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
Copy link

@colinmcdermott colinmcdermott commented Dec 29, 2018

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

@talldan
Copy link
Contributor

@talldan 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
Copy link

@colinmcdermott 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
Copy link

@pfvks pfvks commented Jan 8, 2019

Having the same issue on Safari.

@colinmcdermott
Copy link

@colinmcdermott colinmcdermott commented Jan 8, 2019

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

@StudentDawid
Copy link

@StudentDawid StudentDawid commented Jan 8, 2019

Same issue

@patrizz
Copy link

@patrizz patrizz commented Jan 12, 2019

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

@colinmcdermott
Copy link

@colinmcdermott 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
Copy link

@dleigh dleigh commented Jan 18, 2019

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

@jimtrue
Copy link

@jimtrue 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
Copy link
Member

@designsimply 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
Copy link
Contributor

@pglewis 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
Copy link
Member

@aduth 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
Copy link
Contributor

@pglewis 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
Copy link

@jimtrue 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 ;)

@aduth
Copy link
Member

@aduth 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)

@aduth
Copy link
Member

@aduth aduth commented Mar 1, 2019

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
Copy link
Contributor

@youknowriad youknowriad commented Oct 29, 2019

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet