-
-
Notifications
You must be signed in to change notification settings - Fork 3k
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 jumps to end of editorComponent text
field in v2.10.97
#5092
Comments
Hi @mikestopcontinues, I was unable to reproduce this using your example (the cursor doesn't jump for me). Also, this doesn't happen with any of the blocks in https://cms-demo.netlify.com/#/collections/posts/new. Perhaps share a public repo and a video/gif showing the issue? |
Hi @erezrokah Here's a reproduction. Sorry I didn't lead with one. In my own experimentation, it's only the https://codepen.io/mikestopcontinues/pen/PobXQxO And here's the goal state, which does some parsing to/from markdown. The issue is the same. Including it just for context. |
I'm also experiencing cursor jumping to the end of text fields that are inside a component in markdown. I'm using: |
App recently started experiencing this behaviour, any updates on the issue? netlify-cms-app@^2.15.72 For what it's worth it is not happening in Safari. |
I can confirm @josephmasongsong report that this bug is active again. [email protected] Firefox (104.0.2 (64-bit)) does not have the issue. |
My team is seeing this bug as well. I was not seeing it, and then I updated to Chrome Version 105.0.5195.102, and then I was seeing it. Looks like it has something to do with the newest version of Chrome |
I'm getting this too, starting from when I upgraded to Chrome 105.0.5195.102 (Official Build) (x86_64). netlify-cms-app 2.15.72 CMS.cursor.prob.mov |
Friendly bump on this issue, our content team started experiencing this issue after upgrading to Chrome 105. |
I think the proper fix for now is
|
Thanks, I'll try it but hello Netlify, it's been 3 years since bug exists |
@h1sashin I've just struck the same bug and landed here on my research. |
Same here on Brave 1.43.89 Chromium: 105.0.5195.102. Makes any kind of back-editing practically impossible without the fix provided by @johnxie and/or @aledovskikh |
Any plan on fixing this? is there a PR already? I posted the same issue over here #6557 |
How do you apply the fix as I can't work that out? I am using netlify CMS with an 11ty site. |
@sawilde Add the following code in the header of the
|
@marcojakob thank you very much |
Hi, I am using netlify CMS with gatsby js, and am confused how to apply this fix, can someone help me |
@amantulsyan35 I don't know how the gatsby setup works but in my setup I had an admin section with an index.html file that loads the Netlify CMS script, I added it in there as described by @marcojakob |
Still an issue when using CDN version of CMS |
I'm still encountering this issue, and the above fix didn't work for me. I'm using a list widget as an editor component, and I have two text areas in each list item that are having this problem - a code widget, and a text widget. The string widget is working fine and doesn't jump the cursor to the end. For the
However, I'm still having this problem with the text widget, and the original suggestion to use the |
This appears to be caused by ianstormtaylor/slate#5110 so the fix is likely upgrading the version of slate used by the netlify-cms-widget-markdown package. It's likely worth updating the recommended Happy to PR the workaround into the various docs, not sure I have the bandwidth to update Slate from 0.47 to 0.94 but if that's on the team's radar it's probably the better fix |
But here it is said that it is a non-standard feature and shouldn't be used for production sites. |
@ali4zimi since this is only a css rule, I don't see why it wouldn't be used on production sites. I think it's safe. |
wait, what is the workaround? (because the css doesn't work with dead keys which is important for writing in portuguese and other languages as well) |
The workaround is the CSS change. It's not a fix but right now no one who freshly deploys according the documentation can use the markdown editor, in any language. The correct fix is to update the library or make a new markdown control using a different library. I don't have the bandwidth to do that but @vhoyer given it's blocking you you might consider investigating that. Worth reviewing #5795 as it looks like there is some discussion about versions and switching editors there |
Fixes #16 A stale bug in Decap CMS. 3 Years old and unlikely to be fixed. Longer term as this system seems to be used, should either replace decap or vendorise and fix it. decaporg/decap-cms#5092
It fix cursor issue (decaporg/decap-cms#5092)
* Configure "Legacy Help Sections" resource to support importing existing content * Output clean JSON files instead of relying on page-data artifacts * Move search index to JSON pages * Remove unused content and configuration * Set up docker volumes for local development * Add workaround for text editor cursor bug: decaporg/decap-cms#5092 (comment)
* Configure "Legacy Help Sections" resource to support importing existing content * Publish clean JSON files instead of the whole page-data artifacts * Remove unused content and configuration * Set up docker volumes for local development * Add workaround for text editor cursor bug: decaporg/decap-cms#5092 (comment)
* Configure "Legacy Help Sections" resource to support importing existing content * Publish clean JSON files instead of the whole page-data artifacts * Remove unused content and configuration * Set up docker volumes for local development * Add workaround for text editor cursor bug: decaporg/decap-cms#5092 (comment)
* Configure "Legacy Help Sections" resource to support importing existing content * Publish clean JSON files instead of the whole page-data artifacts * Remove unused content and configuration * Set up docker volumes for local development * Add workaround for text editor cursor bug: decaporg/decap-cms#5092 (comment)
For those still facing this issue:For Gatsby: (using
For others using |
Experimenting based on decaporg/decap-cms#5092 (comment)
Describe the bug
It looks like bugs #4539 and #3578 have returned.
To Reproduce
Expected behavior
I expect the cursor to hold its position.
Applicable Versions:
The text was updated successfully, but these errors were encountered: