1847949 - Posting clipboard contents with newlines completely breaks Twitter comments and posts when dom.event.clipboardevents.enabled=FALSE

Status: RESOLVED INVALID

(Core :: DOM: Copy & Paste and Drag & Drop, defect, P3)

Description

[Artem S. Tashkinov]

Attachment: example.png

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:109.0) Gecko/20100101 Firefox/114.0

Steps to reproduce:

Steps to reproduce:

1. Copy the below text to the clipboard buffer:

String1 one one
String2 two two

2. Now paste into the comment in Twitter

Actual results:

The entire edit field BREAKS completely, see the attached screenshot.

You can no longer edit it or do anything, the entire edit field is BROKEN.

Expected results:

I'm mad as f because this bug is now at least 20 years old. Why no one has solved it is beyond me.

The same applies to Facebook comments/posts as well. Probably to Disqus comments as well.

This is under Firefox (the official release downloaded from https://ftp.mozilla.org/pub/firefox/releases/ ) for Linux running in SAFE mode, i.e. no add-ons can be responsible for this utterly broken behavior.

Comment 1

[Artem S. Tashkinov]

In rare cases it works, but I'm using mousepad (a graphics text editor) with these two strings.

Comment 2

[Artem S. Tashkinov]

Attachment: Bug 1847949.mkv

Here's a video of doing that.

Then I press Ctrl + Home and try to "Delete" everything.

It falls apart completely.

Comment 3

[BugBot [:suhaib / :marco/ :calixte]]

The Bugbug bot thinks this bug should belong to the 'Core::DOM: Copy & Paste and Drag & Drop' component, and is moving the bug to that component. Please correct in case you think the bot is wrong.

Comment 4

[BugBot [:suhaib / :marco/ :calixte]]

The severity field is not set for this bug.
:edgar, could you have a look please?

For more information, please visit BugBot documentation.

Comment 5

[Jan Jaeschke [:jjaschke]]

Artem,
thank you for reporting. Do you maybe have a test case which does not require an account (as Twitter or Facebook does)?

Comment 6

[Emilio Cobos Álvarez (:emilio)]

The fact that this only happens on Windows, and only on newlines, makes me think we might be doing something odd with windows-vs-unix-style new lines?

Do you know if this works on Nightly? We've stopped normalizing windows style newlines there, see bug 1850819.

Comment 7

[Sean Feng [:sefeng]]

I think this was on Linux as to what the reporter said in the description.

Comment 8

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

(In reply to Emilio Cobos Álvarez (:emilio) from comment #6)

The fact that this only happens on Windows, and only on newlines, makes me think we might be doing something odd with windows-vs-unix-style new lines?

In the editor module, we check platforms only when setting caret style and handling special shortcut key for RTL language users.
https://searchfox.org/mozilla-central/search?q=%23if&path=editor%2Flibeditor%2F&case=true&regexp=false

Additionally, we basically handle LF as line breaks, but CRLF may appear in the DOM tree if web apps insert intentionally.

Comment 9

[Artem S. Tashkinov]

(In reply to Jan Jaeschke [:jjaschke] from comment #5)

Artem,
thank you for reporting. Do you maybe have a test case which does not require an account (as Twitter or Facebook does)?

Unfortunately I am not aware of any other websites with this issue.

Comment 10

[Artem S. Tashkinov]

This is STILL unresolved for f's sake.

Looks like no one bloody cares.

You can trivially reproduce this under Windows as well. Copy text without Windows line breaks, instead containing Linux line breaks. Try to paste it, it's ALL BROKEN. The comment form breaks down completely.

Comment 11

[Artem S. Tashkinov]

11 releases after and whelp, you're on your own. And I've been dealing with this critical bug for a decade now.

Comment 12

[Artem S. Tashkinov]

And of course no a single Mozilla employee can sign up on Twitter to fix it. No way.

Except you've got multiple accounts already.

Comment 13

[Artem S. Tashkinov]

Why have my comments been hidden?

We are talking about a core browser feature which is BROKEN. Not in Google Chrome, Edge or any other web browser.

I'm quite sure that it will take at most an hour for a single developer to fix it.

Comment 14

[Artem S. Tashkinov]

Maybe you should just close bugzilla completely if people complaining about core browser features being broken is considered "advocacy".

Advocacy of what exactly? Of having a usable browser?

Comment 15

[Artem S. Tashkinov]

This is not something which is difficult or impossible to reproduce either.

It can be reproduced in a minute if you have Linux installed and you have an email address. That much time is required to sign up on Twitter or Facebook.

Comment 16

[Kagami Rosylight [:saschanaz] (they/them)]

I cannot immediately reproduce this on my Steam OS installation, can you provide more information about your Linux configuration, e.g. which Linux distribution you are using, the versions of the distribution and Firefox, and whether you have installed any specific input framework e.g. ibus?

Also if you don't mind, can you check whether the same happens on flatpak Firefox distribution?

Edit: I cannot reproduce on Windows either, with navigator.clipboard.writeText("String1 one one\nString2 two two") to force \n instead of \r\n.

Comment 17

[Jan Jaeschke [:jjaschke]]

Hello Artem,

Your comments have been hidden because they do not add additional value and have become slightly toxic. We understand your frustration about a feature being broken for a long time. I can assure you that such things are often not being fixed “by a single developer in an hour” (our lives would be much easier if that were the case).

We are currently having trouble reproducing the issue, even with twitter accounts. It seems that there must be something different in your setup compared to what we tried, so let’s try to bisect this and find out the root issue. But let’s do this in a civilized manner.

Comment 18

[Artem S. Tashkinov]

I'm using:

• Fedora 40 with XFCE
• Mozilla's own Firefox build (https://ftp.mozilla.org/pub/firefox/releases/127.0.1/linux-x86_64/)

I'd be glad to give you any information to help fix the issue.

Comment 19

[Artem S. Tashkinov]

Sorry I didn't know and I couldn't have imagine that one of my settings that I'd had for years if not decades could have broken modern websites relying on some new fancy JS features.

Turns out I've had dom.event.clipboardevents.enabled=FALSE and it wrecks havoc not only to Twitter but to Disqus as well, bug 1909124.

With this option set to default (true) Twitter now works as expected. Darn. I've been suffering for years. Both bugs can probably be closed as INVALID/WONTFIX. Suit yourself.

Comment 20

[Artem S. Tashkinov]

And I'm not alone, https://utcc.utoronto.ca/~cks/space/blog/web/FirefoxClipboardeventsIssue

A Firefox surprise from disabling dom.event.clipboardevents.enabled
April 16, 2021
One of the things that browsers allow sites to do with JavaScript is to intercept and manipulate attempts to copy text out of them or paste text into them. Websites use this to do obnoxious things like stop you pasting email addresses and passwords into their forms or mangling the text you copy out (via, and this is potentially a security risk since what you think you're going to paste is not necessarily what you actually get). When I heard about this at some point (I'm not sure when, but it was no later than mid 2016), I went into about:config in all of my Firefox instances and disabled the dom.event.clipboardevents.enabled preference, which makes Firefox ignore Javascript attempts to interfere with cut and paste. Everything went along fine for years and years, with no visible downside, and I completely forgot about it.

(According to some searching of MDN, this controls HTMLElement.oncopy, HTMLElement.onpaste, and HTMLElement.oncut.)

Recently I wanted to copy some Grafana panels from one Grafana server to another, which in the modern web application way you do by viewing the JSON that defines the panel, copying it to the clipboard, going to the tab with your dashboard on the other server, and pasting in the JSON to overwrite the configuration of some victim panel. Old versions of Grafana had a handy 'copy to clipboard' button that did this for you, but in 7.5 you have to do it by hand. the menu item). Whenever I did this, I got mangled text, with most of the JSON elided and replaced with a '…' Unicode character.

After help from several people and experimentation with a completely clean Firefox profile, I narrowed this down to having dom.event.clipboardevents.enabled disabled. I don't know exactly what Grafana is doing here with its HTML, DOM, CSS, and JavaScript, but apparently it absolutely has to post-process the text when it's copied or you get something that isn't even the text being currently displayed on the screen, much less the full JSON that you need.

In light of this glitch (and because working with Grafana is somewhat important for me), I've reverted this preference to its default enabled state. In my main Firefox, this is pretty harmless because I have JavaScript almost entirely disabled through uMatrix, so websites can't intercept my cut and paste in the first place. In the Firefox profile I have to run all the sites that need JavaScript, I will have to hope that I don't run into any that refuse to let me paste or copy text; if I do, I will have to temporarily toggle the preference again. Hopefully the increase in password managers has made websites less silly about pasting things into form fields.

(Via this article I found a suggestion of the Luminous addon, but brief experimentation suggests that something like Grafana is completely beyond the ability of an addon like this to do anything sensible with.)

(This elaborates on some tweets. I'm not sure I'd know about Ctrl-A and Ctrl-C before, although I really should have; they're right there in Firefox's 'Edit' menu. Which I almost never look at.)

Comment 21

[Kagami Rosylight [:saschanaz] (they/them)]

Okay, I tried today again with the pref disabled and it seems I can reproduce this on X (either on comments or the main input box). It does not break completely but certainly behaves bad (as pasting "ABC\nBCD" becomes "\nABCBCDABCBCD").

But do we even want to support disabling clipboard events? If we don't (as Jan pointed out in bug 1909124), should we remove the pref?

Comment 22

[Kagami Rosylight [:saschanaz] (they/them)]

Forgot NI to Jan for comment #21.

Comment 23

[Jan Jaeschke [:jjaschke]]

I can't assess if the privacy concerns mentioned in comment 20 and in bug 1909124 are still valid.

I'm wondering if bug 1670383 (having separate prefs for copy and paste) would improve the situation?

Comment 24

[Kagami Rosylight [:saschanaz] (they/them)]

I don't think we should maintain privacy by turning the APIs off, we should rather make the API no-op for that purpose, if we want to support that. And if we want to do that, maybe splitting would make sense.

Comment 25

[Artem S. Tashkinov]

I have an idea.

Firefox could show a notification/popup/whatever when the website changes the clipboard contents.

This way the user can at least exercise caution when dealing with something potentially malicious.

To me it warrants a new bug report anyways.

Comment 26

[Kagami Rosylight [:saschanaz] (they/them)]

That would only work for clipboard write, because for clipboard read there's no good way to detect the script behavior. And yet there are many valid use case to write synthesized clipboard content, e.g. when you click Copy button or the source is not in plaintext but something complex. And I think we generally are not for notifications because that'll cause user fatigue. (The permission prompts already are enough for fatigue.)

I think the general pain point is about the overwritten clipboard write (as the page can do whatever it wants to do with clipboard read result anyway), we could try some heuristic to prevent plaintext-to-plaintext case at least. (Some websites are being annoying by adding page link in the write result, for example.)

Comment 27

[Artem S. Tashkinov]

we could try some heuristic to prevent plaintext-to-plaintext case at least. (Some websites are being annoying by adding page link in the write result, for example.)

+1 from me.

Comment 28

[Jan Jaeschke [:jjaschke]]

Let's move this discussion over to bug 1670383 and close this one.