decaporg / decap-cms

A Git-based CMS for Static Site Generators
https://decapcms.org
MIT License
17.9k stars 3.04k forks source link

Cursor jumps to end of editorComponent `text` field in v2.10.97 #5092

Open mikestopcontinues opened 3 years ago

mikestopcontinues commented 3 years ago

Describe the bug

It looks like bugs #4539 and #3578 have returned.

To Reproduce

  1. Register editorComponent with text field (below).
  2. Create document, add component, add text to text field.
  3. Move pointer to anywhere but the end of the text field input.
  4. Try to type.
  5. After one character, the cursor jumps to the end.
const typeToPre = {
  bonus: '+>',
  info: '!>',
  warning: '?>',
  error: '#>',
};
const preToType = R.zipObj(R.values(typeToPre), R.keys(typeToPre));

CMS.registerEditorComponent({
  id: 'hint',
  label: 'Hint',

  fields: [
    F.select({label: 'Type', name: 'type', options: R.keys(typeToPre)}),
    F.text({label: 'Text', name: 'text'}),
  ],

  pattern: /^([!#+?]>) (.+)$/,

  fromBlock([_, pre, text]) {
    return {type: preToType[pre], text};
  },

  toBlock({type, text = ''}) {
    return `${typeToPre[type]} ${text}`;
  },

  toPreview({type, text = ''}) {
    return (
      <p
        className={`hint ${type}`}
        dangerouslySetInnerHTML={{__html: text}}
      />
    );
  },
});

Expected behavior

I expect the cursor to hold its position.

Applicable Versions:

erezrokah commented 3 years ago

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?

mikestopcontinues commented 3 years ago

Hi @erezrokah Here's a reproduction. Sorry I didn't lead with one. In my own experimentation, it's only the text field. The others aren't giving me a problem.

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.

https://codepen.io/mikestopcontinues/pen/QWGzQOr

ChrisPJohn commented 3 years ago

I'm also experiencing cursor jumping to the end of text fields that are inside a component in markdown.

I'm using: netlify-cms-app@^2.14.26 Chrome 89.0.4389.82 OS: Windows

josephmasongsong commented 2 years ago

App recently started experiencing this behaviour, any updates on the issue?

netlify-cms-app@^2.15.72 OS: macOS Monterey Chrome Version 105.0.5195.102 (Official Build) (arm64)

For what it's worth it is not happening in Safari.

carlfredrikhero commented 2 years ago

I can confirm @josephmasongsong report that this bug is active again.

netlify-cms@2.10.192 OS: macOS Monterey Chrome: Version 105.0.5195.102 (Official Build) (arm64)

Firefox (104.0.2 (64-bit)) does not have the issue.

aloverso commented 2 years ago

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

tonyshearer commented 2 years ago

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 netlify-cms-core 2.55.2 netlify-cms 2.10.192

https://user-images.githubusercontent.com/5812027/189841849-4b872744-57cf-4429-b142-0bad1f96bcd6.mov

johnxie commented 2 years ago

Friendly bump on this issue, our content team started experiencing this issue after upgrading to Chrome 105.

johnxie commented 2 years ago

Update from our team. It looks like removing this line will fix the issue.

screen_shot_2022-09-14_at_2 46 02_am

Video attached

https://user-images.githubusercontent.com/792088/190082126-d13eb60b-023b-45ca-9f8a-6365119e0eb9.mp4

h1sashin commented 2 years ago

Update from our team. It looks like removing this line will fix the issue.

screen_shot_2022-09-14_at_2 46 02_am

Video attached

Sep-14-2022.02-44-52.mp4

yes but can I remove it globally?

aledovskikh commented 2 years ago

I think the proper fix for now is

[data-slate-editor] { 
    -webkit-user-modify: read-write !important; 
}
h1sashin commented 2 years ago

I think the proper fix for now is

[data-slate-editor] { 
    -webkit-user-modify: read-write !important; 
}

Thanks, I'll try it but hello Netlify, it's been 3 years since bug exists

nirazul commented 2 years ago

@h1sashin I wouldn't count on netlify providing anything cms related. They basically stopped developing it.

I've just struck the same bug and landed here on my research.

VitroidFPV commented 2 years ago

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

keogh commented 2 years ago

Any plan on fixing this? is there a PR already?

I posted the same issue over here #6557

sawilde commented 2 years ago

How do you apply the fix as I can't work that out? I am using netlify CMS with an 11ty site.

marcojakob commented 2 years ago

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 index.html file where the Netlify CMS JavaScript is loaded. That works for me:

<style>
[data-slate-editor] { 
    -webkit-user-modify: read-write !important; 
}
</style>
sawilde commented 2 years ago

@marcojakob thank you very much

amantulsyan35 commented 2 years ago

I think the proper fix for now is

[data-slate-editor] { 
    -webkit-user-modify: read-write !important; 
}

Hi, I am using netlify CMS with gatsby js, and am confused how to apply this fix, can someone help me

sawilde commented 2 years ago

@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

image
josephmasongsong commented 1 year ago

I think the proper fix for now is

[data-slate-editor] { 
    -webkit-user-modify: read-write !important; 
}

Hi, I am using netlify CMS with gatsby js, and am confused how to apply this fix, can someone help me @amantulsyan35

I used this solution for Gatsby.

https://answers.netlify.com/t/change-admin-css-to-tweak-a-bit-the-cms-ui-defaults/17835

JKarlavige commented 1 year ago

Experiencing this on our end as well, occurring in the markdown widget. Applying the style fix noted here fixes it for us.

Using Chrome Version 107.0.5304.87 (Official Build) (arm64)

vhoyer commented 1 year ago

This solution doesn't work for me, when I need to write with dead keys (pt-BR with accent marks, and what not)

Outlook for Androidhttps://aka.ms/AAb9ysgを取得


From: Jason Karlavige @.> Sent: Tuesday, November 8, 2022 6:41:02 PM To: netlify/netlify-cms @.> Cc: Vinícius Hoyer @.>; Manual @.> Subject: Re: [netlify/netlify-cms] Cursor jumps to end of editorComponent text field in v2.10.97 (#5092)

Experiencing this on our end as well, occurring in the markdown widget. Applying the style fix noted here fixes it for us.

Using Chrome Version 107.0.5304.87 (Official Build) (arm64)

― Reply to this email directly, view it on GitHubhttps://github.com/netlify/netlify-cms/issues/5092#issuecomment-1307864982, or unsubscribehttps://github.com/notifications/unsubscribe-auth/ACUDBAADA335HUCQRKRD433WHLCG5ANCNFSM4Y7XZBEA. You are receiving this because you are subscribed to this thread.Message ID: @.***>

nejurgis commented 1 year ago

The solution works, just don't forget to import the cms-utils.js into your cms.js file

alianza commented 1 year ago

Is this issue fixed now? Is the style fix not needed anymore?

FrankFlitton commented 1 year ago

Still happening on chrome on Windows and MacOS. Adding the snippet to the header fixed it for me using the Next.js template referenced in the docs.

pjr94 commented 1 year ago

Still an issue when using CDN version of CMS

ashleykolodziej-moodys commented 1 year ago

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 code widget, I was able to get the right behavior by using this CSS snippet in admin/index.html instead (notice the change in selector to textarea:

<style>
      /* Workaround for text editor https://github.com/decaporg/decap-cms/issues/5092 */
      textarea {
        -webkit-user-modify: read-write !important;
      }
</style>

However, I'm still having this problem with the text widget, and the original suggestion to use the [data-slate-editor] selector isn't working for me. Maybe there's something with how the list widget updates child items that doesn't work with this workaround for the text widget? If anyone has any leads on a fix for this situation, I'd appreciate it.

kav commented 1 year ago

This appears to be caused by https://github.com/ianstormtaylor/slate/issues/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 index.html with the workaround if upgrading slate isn't in the cards near term as this is a near universal issue at this point.

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

ali4zimi commented 1 year ago

I think the proper fix for now is

[data-slate-editor] { 
    -webkit-user-modify: read-write !important; 
}

But here it is said that it is a non-standard feature and shouldn't be used for production sites.

martinjagodic commented 1 year ago

@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.

vhoyer commented 1 year ago

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 index.html with the workaround if upgrading slate isn't in the cards near term as this is a near universal issue at this point.

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

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)

kav commented 1 year ago

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 https://github.com/decaporg/decap-cms/issues/5795 as it looks like there is some discussion about versions and switching editors there

hiiiP0wer commented 7 months ago

For those still facing this issue:

For Gatsby: (using gatsby-plugin-netlify-cms)

  1. Include this in gatsby-config.js:
    {
      resolve: 'gatsby-plugin-netlify-cms',
      options: {
        modulePath: `${__dirname}/src/cms/cms.js`
      }
    }
  1. Create the file referenced in modulePath prop above and add this in the cms/cms.js file:
    
    const injectCustomStyle = () => {
    const style = document.createElement('style');
    style.innerHTML = `
    div[data-slate-editor] {
      -webkit-user-modify: read-write !important;
    }
    `;
    document.head.appendChild(style);
    };

injectCustomStyle();



**For others using `index.html` that loads the Netlify CMS script, this is very helpful: https://github.com/decaporg/decap-cms/issues/5092#issuecomment-1257138396**