Issue with updated https://draftjs.org/ demo editor

[scottfr]

Do you want to request a feature or report a bug?

Bug

What is the current behavior?

The draftjs.org website was recently updated. The new demo editor on the site has a bug with pasting.

Steps to reproduce:

1. Go to https://draftjs.org/
2. Copy and then paste something like "test" into the editor at the bottom of the page
3. Type the left arrow once so the cursor should be before the final "t". E.g. "tes|t" (note do not click, the bug is shown when you use keyboard navigation).
4. Paste again.

The paste will incorrectly be placed at the end of the "test", not at the cursor's location. The results will be "testtest" rather than "testestt".

The old demo editor behaved correctly and did not have this issue.

Running this on the latest version of Chrome.

[mrkev]

Oh huh, this is very odd.

@yangshun updated the website— did you make any changes to the editor too? I wonder what's going on here, it didn't sound like any of this should change haha.

[yangshun]

I didn't make any changes to the editor, but now the editor is loading from npm instead of a hardcoded minified v0.11.3 version loaded via a script tag in Docusaurus 1. So this could be a regression in Draft.js rather than the website itself. I'll try to change to a different version of Draft.js in website/package.json later and see if the problem sticks.

[yangshun]

Upon further investigation, the editor works ok during local development but the generated site has a broken editor. I suspect it's due to the minification step. cc @endiliey for help! Anyway to turn off minification during the build step (other than hacking the local Docusaurus core in node_modules)?

We need to try out the editor on a non-Docusaurus environment like CRA with minification to actually determine if it's Docusaurus' minification that's breaking it.

Repro steps:

---

Update: I set minimize: false in Docusaurus webpack's config and this fixes the issue. So it's quite confirmed it's Docusaurus' minification step, but it could be a bug in one of Docusaurus' minification tools or the way Draft.js is writing the code.

[endiliey]

I think its a bad idea not to minify in prod. Bundle size will be very big. They can easily turn it off with configureWebpack hook (local plugin).

Can you test it on CRA ? Minification is done by Terser (for JS). Our terser options is taken from CRA, so if it doesnt work on ours most likely it doesnt work on CRA. Unless the terser dependency has a bug, or CRA has updated their option

[angelikatyborska]

My project has exactly the same issue as @yangshun presented on the gif.

First weird behavior is that text selection and applying a block element (h1/h2/h3) always seems to apply it to the last line instead of the selected line, exactly like on the gif.

Second weird behavior is that regardless of where you put the cursor, when you start to type, the characters appear somewhere on the last line. The first character that you type appears on the selected line, and then the selected line gets copied into the last line, and if you continue typing, those characters only appear on the last line. Attaching a gif:

We do not use Docusaurus, we have an Elixir Phoenix web app, and it only uses React for this RTE, nothing else. We use webpack with babel-loader.

The problem happens both in production and when running a dev server.

So far we confirmed that this problem appears in

• Firefox macOS Catalina
• Chrome macOS Catalina
• Firefox desktop Linux
• Firefox iOS (iPod & iPad)
• Safari iOS (iPod & iPad)
• Firefox Android 8
• Chrome Android 8

There is no problem on Chrome macOS Catalina and Chrome Linux.

[yangshun]

@angelikatyborska Is there a link to your project that we can access online?

Try turning off the minification in the webpack build step and see if the problem goes away.

[angelikatyborska]

Unfortunately it's a closed-source project of a company I work for, I can't share its code base. I'll try to create a fresh project to reproduce.

The problem appears in our project in both development and production, so I doubt that it's caused by minificatiton. We use uglifyjs-webpack-plugin for production builds, and no minification in dev. Just to be paranoid, I threw uglifyjs-webpack-plugin out of package.json and node_modules, and tried a dev build again, but that didn't help.

[angelikatyborska]

I spent more time going through our project's git history and I found the commit that introduced the bug. Long story short, our RTE broke when we added Cookiebot to our website.

Adding this script to a page with an RTE creates the problems:

    <script id="Cookiebot"
            src="https://consent.cookiebot.com/uc.js"
            data-blockingmode="auto"
            data-culture="en"
            type="text/javascript">
    </script>

Of course I don't expect draft-js to be responsible for other random scripts ;). I'm just writing my finding in case there's somebody else with a similar problem.

[yangshun]

I see, so the bug in your app is not related to the minification process I guess. I wonder what cookiebot is doing that will break the RTE.

[mrkev]

Post

[mrkev]

Couple of notes:

• The site actually seems to be on 11.2. I just PR'd an update to 11.3 here: Update website's yarn version to 0.11.3 #2286
• Specifically, the difference between prod and running it in development is in prod we get Uncaught TypeError: Cannot read property 'getIn' of undefined a few times on every keypress— easy to assume this is related to the wonky behaviour. @angelikatyborska, do you also see this exception?

[mrkev]

From looking at the minified source I'm assuming it refers to this line,

https://github.com/facebook/draft-js/blob/53d2a63a4cfdef68516c4ec487d5529566cd4bf3/src/component/selection/getUpdatedSelectionState.js#L41

Which means we're failing to find the anchorBlockKey.

[angelikatyborska]

@angelikatyborska, do you also see this exception?

No, I experience no exceptions when I get this weird behavior from the gif from #2280 (comment)

[mrkev]

huh, maybe the exception is unrelated and it's a second bug? I'm on PTO until Janurary, so I'll have availability time to look into this, but thanks for letting me know @angelikatyborska

[angelikatyborska]

My issue (#2280 (comment)) suddenly disappeared 🤷‍♀ I assume Cookiebot did a deployment that removed whatever caused the issue. I can't know what that was though because there's no changelogs, no npm packages, just the current minified live version of the script.

[fabiomcosta]

@angelikatyborska I can get the broken behavior on Chrome as well sometimes...

[fabiomcosta]

Upon further investigation, the editor works ok during local development but the generated site has a broken editor. I suspect it's due to the minification step. cc @endiliey for help! Anyway to turn off minification during the build step (other than hacking the local Docusaurus core in node_modules)?

We need to try out the editor on a non-Docusaurus environment like CRA with minification to actually determine if it's Docusaurus' minification that's breaking it.

Repro steps:

Update: I set minimize: false in Docusaurus webpack's config and this fixes the issue. So it's quite confirmed it's Docusaurus' minification step, but it could be a bug in one of Docusaurus' minification tools or the way Draft.js is writing the code.

@yangshun I cloned the repo and ran the website without any changes and got no errors there.
Did anyone try just updating the website with the latest code on master?

[fabiomcosta]

This PR will potentially fix this issue as well, but it was created to fix a separate issue, that happen to be on the same code path of the issue that is happening on the production website.

#2297

[fabiomcosta]

By debugging the issue on the production site I can see that the editorState that we have access on draft-js/src/component/selection/getUpdatedSelectionState.js is not really matching the initial HTML content.
The data-offset-key on the HTML is always data-offset-key="erdqe-0-0", which makes me think that this might be related to some sort of server-sider-rendering issue, and that draft-js doesn't work well with SSR.

[thisispaul]

I have recently encountered this issue and it seems it is definitely due to SSR as @fabiomcosta has pointed out. I had it occurring with a gatsby site only in production and managed to fix it using the workarounds in this issue: #2121

[mrkev]

Disabled SSR-ing the editor in #2356

Checked the site just now and the editor isn't throwing on every keypress any more 👍