Having a 'contenteditable' textarea and invoking `document.execCommand("paste")` causes a multi-line text in the clipboard to get pasted without any newlines. Looking at the DOM, it seems like we're replacing newlines by '<br>' and then inject it as a DOMElement, which doesn't work for textareas. See URL for an example you can play around with. Just load it as a temporary extension.

I should note that the add-on linked in the URL only works as expected because of https://github.com/wagnerand/open-multiple-addresses/blob/read/popup.js#L34: 'textArea.value = textArea.innerHTML.replace(/<br>/g, "\n");'

Rob is becoming our clipboard expert.

Looks like the ever-growing list of bugs with clipboard. The unique situation with WebExtensions is that document.execCommand("paste") can be called by extensions that have the clipboardRead permission. A way to show the buggy behavior on the web is: data:text/html;charset=utf8, <input type=button onclick="out.focus();document.execCommand('insertText',false,'multi\nline\ntext');console.log(out.innerHTML)" value="Add multi-line string to contentEditable textarea"> <textarea contenteditable id=out></textarea> To read the text without \n -> <br> conversion within an extension with the "clipboardRead" permission, use the "paste" event, e.g. as done in https://bugzilla.mozilla.org/show_bug.cgi?id=1344410#c12

use \r\n instead of \n for workaround

Also, we need to check each browser compatibility for this for <br> or \n

(In reply to Andreas Wagner [:TheOne] [use NI] from comment #1) > I should note that the add-on linked in the URL only works as expected > because of > https://github.com/wagnerand/open-multiple-addresses/blob/read/popup.js#L34: > 'textArea.value = textArea.innerHTML.replace(/<br>/g, "\n");' text.innerHTML shouldn't return currnet value data although I ask to WHATWG about textarea.innerHTML's behavior. See https://github.com/whatwg/html/issues/3034. Why do you use textarea.innerHTML for current value?

Hm, I am not sure I follow all of this. I believe the reason I used textarea.innerHTML was so I could actually see where the newlines are and then replace <br> by \n. > To read the text without \n -> <br> conversion within an extension with the "clipboardRead" permission, use the "paste" event, e.g. as done in https://bugzilla.mozilla.org/show_bug.cgi?id=1344410#c12 I am not sure this solves my problem. I don't want to capture the paste event, I want to trigger the paste.

(In reply to Andreas Wagner [:TheOne] [use NI] from comment #7) > > To read the text without \n -> <br> conversion within an extension with the "clipboardRead" permission, use the "paste" event, e.g. as done in https://bugzilla.mozilla.org/show_bug.cgi?id=1344410#c12 > > I am not sure this solves my problem. I don't want to capture the paste > event, I want to trigger the paste. You want to read from the clipboard, and to do so you used execCommand("paste") + reading from a contentEditable textarea. That has bugs, so to access untransformed clipboard data, you can use execCommand("paste") + "paste" event (and read the paste data from event.clipboardData.getData).

(In reply to Rob Wu [:robwu] from comment #8) > You want to read from the clipboard, and to do so you used > execCommand("paste") + reading from a contentEditable textarea. > That has bugs, so to access untransformed clipboard data, you can use > execCommand("paste") + "paste" event (and read the paste data from > event.clipboardData.getData). I am not sure how this is any better than my current workaround (comment 1), since your suggestion also pastes the clipboard into the (visible) textarea and cleans it up afterwards.

(In reply to Andreas Wagner [:TheOne] [use NI] from comment #9) > (In reply to Rob Wu [:robwu] from comment #8) > > You want to read from the clipboard, and to do so you used > > execCommand("paste") + reading from a contentEditable textarea. > > That has bugs, so to access untransformed clipboard data, you can use > > execCommand("paste") + "paste" event (and read the paste data from > > event.clipboardData.getData). > > I am not sure how this is any better than my current workaround (comment 1), > since your suggestion also pastes the clipboard into the (visible) textarea > and cleans it up afterwards. With onpaste you can surely read unmodified data, and with event.preventDefault() you won't even have to "clean up" anything since the document is not modified. And currently you and I know that newlines are broken, but maybe there are even other characters that are unknowingly modified.

Would this exploit take advantage of this? https://github.com/Aaronmsv/PastejackingProtection PoC https://security.love/Pastejacking/