Communication Wizard Refresh when Pasting from Word

[pauldavidmoran]

Description

This is pretty niche, but we've noticed that if you paste copy from Microsoft Word (both directly into the WYSIWYG and the paste from word dialog) in a Text Component (.component.component-text) in the Communication Wizard, it triggers a page load and the pasted content is lost.

Steps to Reproduce

1. Create a New Communication
2. Make your way to the Email Editor
3. Edit an existing Text Component (or create a new one) and paste copy from a Microsoft Word file (or paste copy from Microsoft Word in the paste from word dialog)

Expected behavior:

The pasted copy makes its way into the email.

Actual behavior:

The pasted copy hits the WYSIWYG and then the page is immediately refreshed and the pasted copy disappears.

Versions

• Rock Version: Rock McKinley 8.4 (1.8.4.41)
• Client Culture Setting: en-US

[Tschrock]

I can reproduce this in both Google Chrome and Firefox on the demo site. Our current workaround is pasting everything into Notepad to clear all the formatting first before putting it into the email editor.

[morganw93]

Just tried to reproduce in the demo in v9.1 and it appears to be working as intended. Was this fixed?

[morganw93]

I can't duplicate this on the v9.1 demo or my own v9.3 Rock instance

[nairdo]

@pauldavidmoran or @Tschrock If either of you can confirm you are still seeing this on your v9.2 or greater instance can you kindly re-open this (or let me know).

[jennifertroeger]

I can confirm that this copy/paste refresh (and loss of content) is still happening for us. It is not exclusive to Word (i.e. ANY copy/paste action will do it), and it occurred on v9.4 and now still again on 10.3

[nairdo]

Jennifer, thanks for the update. We're going to look into this one again.

[nairdo]

@jennifertroeger Can you give us a few more details including:

• What web browser are you using?
• Browser's version?
• OS version?
• anything else you think might be relevant

[ghost]

We have a user that showed me this issue yesterday. If she pastes from Word into the editor, it will refresh. If she pastes again, it will work correctly. I can not reproduce on my machine (same OS/browser). I also should mention (not sure if this is related): There is a console error stating that it can't find the RockFileBrowser component. It appears after the refresh happens. I forgot to get the exact log message.

Not sure if any of this information helps at all:

• She is on Mac Mojave (10.14.6)
• Problem happens in Chrome (including incognito)
• CMD+V and right-click, paste both cause refresh
• It did not happen in Safari
• I observed it from Word and Outlook. I will try from Text Edit when I see her this weekend.
• Rock version is 10.3

[milescarmany]

I was able to reproduce this with a specific combination of word processor as the source and paste option.

• macOs Big Sur 11.4 (20F71)
• Google Chrome 90.0.4430.212 (Official Build) (x86_64)
• Apple Pages version 11.0 (7030.0.94) as the source of the text copied
• Using the Paste from Word option in Summernote
• Clicking Insert removes any existing text in the Text Component, but does not add the newly pasted text.
• Trying again works as expected.

Browser console shows the following exception:

select @ summernote.min.js?v=637468768298482204:2
summernote.min.js?v=637468768298482204:2 Uncaught TypeError: Cannot read property 'insertBefore' of null
    at Object.wrap (summernote.min.js?v=637468768298482204:2)
    at gt.wrapBodyInlineWithPara (summernote.min.js?v=637468768298482204:2)
    at gt.insertNode (summernote.min.js?v=637468768298482204:2)
    at summernote.min.js?v=637468768298482204:2
    at Array.map (<anonymous>)
    at gt.pasteHTML (summernote.min.js?v=637468768298482204:2)
    at editor.<anonymous> (summernote.min.js?v=637468768298482204:2)
    at editor.pasteHTML (summernote.min.js?v=637468768298482204:2)
    at Object.invoke (summernote.min.js?v=637468768298482204:2)
    at HTMLButtonElement.<anonymous> (RockHtmlEditorPlugins?v=To2sBYjbsP2V5XppMgA2PwIKNLGzQgewmjaHkO7Z0gU1:1)

[nairdo]

Similar to what was described in issue #5002:

We've change our process how how we process issues that are for external components that we are not able to update ourselves. I'm closing this because it is in a external component. That said we are currently working on a new Obsidian block to replace this one and we'll use a different component for that one.

So, we're closing this one too and have it labeled as "Will Fix In Next Gen".