wymeditor: Adds paste listener to strip superfluous code

laurensmartina commented

2020-10-04 17:25:23 +00:00

(Migrated from github.com)

Fixes #66

laurensmartina commented

2020-10-04 17:26:36 +00:00

(Migrated from github.com)

Based on the #314 by @RoukePouw and processed comments by @matthijskooijman

matthijskooijman commented

2020-10-05 07:58:19 +00:00

(Migrated from github.com)

In #66, I wrote:

One thing to consider: If this catches all pastes, that might be counter-productive when pasting within the wymeditor (e.g. if you want to move a bit of test with markup within a page or article). If that is currently also pasted through a textarea, stripping all markup, that might break things like creating a homepage or newsletter (though you can always paste raw HTML maybe).

I don't think this is addressed in this PR, right? But I think it should be somehow adressed?

In #66, I wrote: > One thing to consider: If this catches all pastes, that might be counter-productive when pasting within the wymeditor (e.g. if you want to move a bit of test with markup within a page or article). If that is currently also pasted through a textarea, stripping all markup, that might break things like creating a homepage or newsletter (though you can always paste raw HTML maybe). I don't think this is addressed in this PR, right? But I think it should be somehow adressed?

laurensmartina commented

2020-10-05 08:16:16 +00:00

(Migrated from github.com)

In #66, I wrote:

One thing to consider: If this catches all pastes, that might be counter-productive when pasting within the wymeditor (e.g. if you want to move a bit of test with markup within a page or article). If that is currently also pasted through a textarea, stripping all markup, that might break things like creating a homepage or newsletter (though you can always paste raw HTML maybe).

I don't think this is addressed in this PR, right? But I think it should be somehow adressed?

Good point! I've raised question as well and talked to @giplt about this. His reaction, and I agree, is that is more preferable to implement this feature now, with the downside that all pastes are stripped and later fix it so that it only targets Word-like code.

> In #66, I wrote: > > > One thing to consider: If this catches all pastes, that might be counter-productive when pasting within the wymeditor (e.g. if you want to move a bit of test with markup within a page or article). If that is currently also pasted through a textarea, stripping all markup, that might break things like creating a homepage or newsletter (though you can always paste raw HTML maybe). > > I don't think this is addressed in this PR, right? But I think it should be somehow adressed? Good point! I've raised question as well and talked to @giplt about this. His reaction, and I agree, is that is more preferable to implement this feature now, with the downside that all pastes are stripped and later fix it so that it only targets Word-like code.

matthijskooijman commented

2020-10-05 17:38:31 +00:00

(Migrated from github.com)

A "copy" event handler exists: https://developer.mozilla.org/en-US/docs/Web/API/Element/copy_event which can probably manually retrieve the selected content, customize it to mark it as "from inside hypha" so that the paste event handler can recognize it and skip the format-stripping.

One way I thought we could mark the data as being "from inside hypha" could be to tweak the "format" on the clipboard. The clipboard typically contains multiple versions (e.g. "text/plain" and "text/html"), and I hoped we could just add an "application/hypha-html" or something in addition to the default types, with identical content to the "text/html" version. However, reading the spec, I think that the formats that can be written from "untrusted" scripts is limited: https://w3c.github.io/clipboard-apis/#writing-to-clipboard.

So I guess adding some wrapper or marker inside the "text/html" version should be done instead. This marker should ideally be invisible and unobtrusive, for the case that this HTML is pasted elsewhere.

We should probably also try to generate a "text/plain" version, to allow copy-pasting from Wymeditor into a plain textarea or so.

A "copy" event handler exists: https://developer.mozilla.org/en-US/docs/Web/API/Element/copy_event which can probably manually retrieve the selected content, customize it to mark it as "from inside hypha" so that the paste event handler can recognize it and skip the format-stripping. One way I thought we could mark the data as being "from inside hypha" could be to tweak the "format" on the clipboard. The clipboard typically contains multiple versions (e.g. "text/plain" and "text/html"), and I hoped we could just add an "application/hypha-html" or something in addition to the default types, with identical content to the "text/html" version. However, reading the spec, I think that the formats that can be written from "untrusted" scripts is limited: https://w3c.github.io/clipboard-apis/#writing-to-clipboard. So I guess adding some wrapper or marker inside the "text/html" version should be done instead. This marker should ideally be invisible and unobtrusive, for the case that this HTML is pasted elsewhere. We should probably also try to generate a "text/plain" version, to allow copy-pasting from Wymeditor into a plain textarea or so.

matthijskooijman commented

2020-10-06 13:17:04 +00:00

(Migrated from github.com)

Rebased and updated the commit message, merging next.

matthijskooijman commented

2020-10-06 13:53:42 +00:00

(Migrated from github.com)

I created #348 for some followup improvements.

Rows
Columns

wymeditor: Adds paste listener to strip superfluous code #345