The problem here is that as soon as we intercept the copy event, we have to override all the data in it - we can't just append metadata to what the browser intendes to write.

• We need to generate our own HTML using getSelection().getRangeAt(0).cloneContents(). This may have subtle differences from what the browser generates:
  • DOM restructuring may happen, although using a <template> element instead of a <div> should reduce this
  • Browsers tend to add inline styles to preserve appearance - this may be hard to recreate. Not having the the inline styles may be considered an improvement by some.
• We need to generate out own plaintext which may differ subtly from what the browser generates.
• We need to fixup the RDFa attributes which are not preserved by Firefox
• Firefox supports multiple selections of disjoint ranges (by holding ctrl) so this would need to be supported too

Is there something specific which we can do on the Parsoid side, or is this just "tracking" for us?

I begin work on T409187: The `data-mw` attribute should be reserved for Parsoid use; rename data-mw="interface" to data-mw-interface in part to provide VisualEditor an unambiguous indicator (presence of data-mw attributes) of whether the pasted content is MediaWiki DOM Spec aka Parsoid output.