Cannot copy paste atomic nodes in Chrome

[ahixon]

Issue details

Chrome, and possibly Webkit, doesn't seem to differentiate easily between sequential nodes that are atomic (contain no directly editable content).

Despite the div being entirely selected (either by clicking, or by programatically creating a NodeSelection), trying to copy/paste in Chrome causes no copy event to fire within the contentEditable.

Steps to reproduce

https://heather-shape.glitch.me/

https://glitch.com/edit/#!/heather-shape

In Chrome, select any of the middle "uneditable" nodes and try to copy them.

Chrome does not generate a copy event. Unsetting contenteditable="false" allows the node to be copyable.

The end nodes (1 and 4) copy correctly.

As above, trying to create a NodeSelection manually around any of those nodes will create the selection, but any copy keyboard events do nothing.

ProseMirror version

Versions that are available via the examples require.

Also exhibited with:

"prosemirror-model": "^1.6.1",
"prosemirror-view": "^1.6.7"

Affected platforms

• Chrome
• Firefox
• Internet Explorer
• Other

Possible workaround

Interestingly, changing the toDOM to serialise the nodes to an object rather than a div or similar element allows the node to be selected, copy and pasted correctly.

I'm not sure how cross browser this is, or if this is even a solution for Prosemirror to handle.

[marijnh]

Ugh. I'm not sure if the browser is intentionally deciding that copying makes no sense when uneditable content is selected or if it's just bugging out somehow, but yeah, that's awkward.

I haven't been able to find a reasonable fix on the library level yet, but adding either draggable: true or style: "user-select: none" to the uneditable element works around the issue.

[marijnh]

Attached patch might be a reasonable workaround, but I'm not entirely sure it won't have side effects. Could you give it a try and see how well it works for you?

[ahixon]

Sorry for the long delay.

Unfortunately this patch doesn't work for me. Enabling/disabling dragging has no effect on copy-ability of these nodes in Chrome. This might be because my usecase renders deeply nested divs inside the NodeView.

We were previously using the <object> workaround, but turns out it has layout problems when attempting to float the element.

Setting contenteditable="true" has success. Of course, we probably only want to turn this kludge on for Chrome. Other browsers draw the ugly resize handles/exhibit odd behaviour in this case.

I've attached a patch (please use the one below, oops) where we turn it on for atomic nodes. Out of interest, why do we explicitly disallow setting the value of contenteditable? Widgets, for instance, already have the (admittedly undocumented) raw setting.

[marijnh]

Making such nodes editable means that typed text might end up inside them (for example, in Chrome, when they are the only child of their parent textblock that seems to commonly happen). As such, this solution doesn't look very attractive.

[ahixon]

Yeah, good point.

Would only modifying the "content-editable" attribute if it hasn't already been set by the nodeview constructor sound reasonable?

[marijnh]

That'd be a reasonable (if somewhat obscure) way to opt out of the setting of contenteditable to false, I guess. You'd still need to address the issues around typing next to such a node, but if you've explicitly set it to editable it sounds okay for the library to treat that as your own responsibility. I'd be okay with a PR that add this behavior.

[qinbinhua601]

@ahixon I happeded to run into this issue too in my project. And I was able to solve this issue by setting one line css to the .ProseMirror-selectednode[contenteditable="false"] selectors -webkit-user-modify: read-write; (see the red box in the screenshot below for the Steps to reproduce glitch demo):

But I don't see the logic here for doing this. Would be appreciate, if anyone could explain more detail for why this worked.

[marijnh]

And I was able to solve this issue by setting one line css

Won't that CSS make the node editable again, though? (With all the problems, such as typed content accidentally ending up somewhere inside it, that entails.)

I don't see the logic here for doing this

I'm not sure what 'this' refers to in this sentence.

[qinbinhua601]

Won't that CSS make the node editable again, though? (With all the problems, such as typed content accidentally ending up somewhere inside it, that entails.)

Yes, it's the werid part of the behavior by the browser by setting both contenteditable="false" and -webkit-user-modify: read-write;. I don't see anything obvious wrong by setting this css, it acted like not setting it in my case. But the copy event really triggered.

I don't see the logic here for doing this

I'm not sure what 'this' refers to in this sentence.

'this' refers to setting -webkit-user-modify: read-write; to .ProseMirror-selectednode[contenteditable="false"] selector which seemed to be a work around for me in my project to this issue.

[danielleshwed]

I'm having this same issue. Non content editable nodes will sometimes be copiable - other times the copy event doesnt fire at all.

it seems worse when there are multiple non editable nodes next to each other vs if there is editable content in between non editable nodes

is there anyone who has discovered a reasonable fix for this?