Element-web: Pasting text into composer is buggy with Firefox when dom.event.clipboardevents.enabled is disabled

[non-Jedi]

Description

Pasting into the editor if not at beginning of a message makes it look like the message was composed correctly, but upon sending, the pasted text is not sent.

Steps to reproduce

• Disable dom.event.clipboardevents.enabled in about:config
• Click on editor
• Type \
• Type \

Version information

• Platform: web

For the web app:

• Browser: Firefox 61.0
• OS: Void linux
• URL: riot.im/develop

[non-Jedi]

This one is especially annoying when trying to quote text by pasting it after a ">".

[non-Jedi]

Actually, only certain copy-pasted text seems to trigger this bug? Didn't trigger on a GH URL...

Following is text originally used to trigger bug:

If there are significant changes to the core ideas, it may be better to
start a new MSC (with links back to the old one), rather than having a
single, long, sprawling

[t3chguy]

were you in RT mode and is the content you pasted in Rich?

[non-Jedi]

Not entirely sure what that means, so here's a gif:

[lampholder]

Thanks for sending the gif!

The gif shows some odd behaviour - we certainly shouldn't see the placeholder text whilst there's text in the composer.

Perhaps I'm misinterpreting, but I can't see the gif representing the problem originally described. Do you try and send the message in the gif? (It's a bit hard to tell where it loops)

[non-Jedi]

Yep. When the blank message gets sent is when i press enter with pasted text. Other behavior was included in the gif as it seemed related.

[t3chguy]

I cannot repro :(

[lampholder]

I can't repro either :( @non-Jedi can you still reproduce this?

[non-Jedi]

I can still reproduce. It seems to be a firefox-specific issue though.

[non-Jedi]

Just to make sure, I disabled all firefox extensions/add-ins, and I can still consistently reproduce the issue.

[l0b0]

I can reproduce with any rich text input 100% of the time, both with middle mouse button and Ctrl-v.

Workaround: Paste the text to a plain text editor such as GitHub's comment editor or Vim, then copy+paste that.

The symptoms after pasting:

• The pasted text appears on the line below the current input, even if there is no newline in the pasted text.
• The caret position is no longer related to the input.
• I can't see any characters I type.
• On refreshing I can see the text I typed both before and after pasting, but the pasted text is not part of that text.
• The effects are slightly different when there are multiple lines of input, but that's probably beyond the scope of this ticket.

In short it's as if the text after pasting appears in a layer on top of the actual input field.

Using Firefox 61.0.2 on up-to-date Arch Linux.

Server info:

matrix-react-sdk version: \ riot-web version: 0.16.0
olm version: 2.2.1

[turt2live]

Out of interest, has this issue gone away for people on riot.im/develop as of today?

[non-Jedi]

@turt2live nope. Still getting the same behavior on riot.im/devel with Firefox.

[turt2live]

I can't reproduce this on Windows. Are people with OSX able to reproduce this at all? It's very possible it's a Linux-only problem.

[aaronraimist]

@turt2live I can't reproduce on macOS (but I can't reproduce on Ubuntu either so maybe I'm doing something wrong).

[aaronraimist]

@l0b0 @non-Jedi What desktop environments are you using?

[l0b0]

I'm using up-to-date Arch Linux, LightDM and Awesome WM.

This issue affects any and all formatted text. Anything I paste (unlike @igh2 this includes parts of the single line of unformatted text I've typed into the Riot editor) I first have to drop into a plain text editor or terminal to avoid triggering this issue.

This is on riot-web version 0.17.3

[non-Jedi]

Qtile. But problem exists if I run Firefox without any de or wm as well.

EDIT: To be clear, I'm saying that the problem exists if I do something like the following in a tty before starting X:

X & DISPLAY=:0 firefox

[non-Jedi]

let me double check that problem isn't isolated to single computer when I get a chance.

[mvgorcum]

I was able to reproduce this bug in firefox on windows 7 on riot.im/app.

[igh2]

This is limiting Riot's usefulness for anything other than stream-of-consciousness messaging. These are my results with Firefox 63 on Fedora 29 with GNOME, pasting into a markdown-enabled editor field.

• Pasting a single line of plain text works as expected.
• Pasting a single line of text with in-line formatting (bold, italics, etc.) works as expected.
• Pasting text with line breaks results in the loss of all line breaks in the editor field.
• Pasting text that includes a blockquote indicated by a greater-than at the start of each line of the block results in a loss of the line breaks in the editor field, and the greater-thans are included literally in the mass of text.
• Pasting text that ends with a blockquote delimited by a pair of three-back-ticks results in nothing showing in the editor field except the last three-back-ticks.
• Pasting text that includes a blockquote delimited by a pair of three-back-ticks and has text following the blockquote results in nothing showing in the editor field except the text that followed the blockquote.

[sandys]

im facing the exact same issue. this is a huge usability issue. and is affecting our ability to use it. Is riot using slatejs ? https://github.com/ianstormtaylor/slate

[knochenhans]

Hi, I’m experiencing exactly the same problem with riot in Firefox for some months now, making pasting virtually impossible for me. I’m on Arch Linux, MATE desktop, X.org.

Added to that, when I paste an URL, riot keeps adding some weird characters to it (%EF%BB%BF), making the links impossible to open by my chat partners.

[absorber]

I made a video about this. It seems to be indeed Firefox-specific and was present in the old Riot Web UI as well as the new re-design: https://youtu.be/4OeOR6dXAQk

Steps to reproduce:

1. Go to a random Wikipedia article (in my example I went to here)
2. Select and copy text in that Wikipedia article.
3. Paste it into the text input field of Riot Web.
4. Select all of the text you have pasted into the text input field (I did Ctrl+a)
5. Press the Backspace or Delete key.

Expected behavior: Text gets deleted.
Observed behavior: Text does not get deleted, unless you switch to another channel and back.

Same happens with plaintext, however there I could reproduce the behavior by cutting and pasting a part of the text into the input itself.

I'm on Firefox 65.0 (64-bit) and Ubuntu 16.04 with i3wm running without compositor.

[t3chguy]

@sandys Yes Riot is using Slate

[absorber]

@t3chguy I'm guessing it might be a Slate.js bug then. If I go to https://www.slatejs.org/#/rich-text and repeat my steps to reproduce, I get this error:

An error was thrown by one of the example's React components!

Q@https://www.slatejs.org/main-e8e0520e642ae32de49e.js:1:152177
Se@https://www.slatejs.org/main-e8e0520e642ae32de49e.js:1:157514
ea@https://www.slatejs.org/main-e8e0520e642ae32de49e.js:1:178988
a/n.updateSelection@https://www.slatejs.org/main-e8e0520e642ae32de49e.js:1:181441
value@https://www.slatejs.org/main-e8e0520e642ae32de49e.js:1:183374
Yo@https://www.slatejs.org/main-e8e0520e642ae32de49e.js:22:84561
Zo@https://www.slatejs.org/main-e8e0520e642ae32de49e.js:22:81001
Vo@https://www.slatejs.org/main-e8e0520e642ae32de49e.js:22:80500
Wo@https://www.slatejs.org/main-e8e0520e642ae32de49e.js:22:80326
Go@https://www.slatejs.org/main-e8e0520e642ae32de49e.js:22:79699
yo@https://www.slatejs.org/main-e8e0520e642ae32de49e.js:22:78931
enqueueSetState@https://www.slatejs.org/main-e8e0520e642ae32de49e.js:22:54467
k.prototype.setState@https://www.slatejs.org/main-e8e0520e642ae32de49e.js:14:1268
a/n.onChange@https://www.slatejs.org/main-e8e0520e642ae32de49e.js:42:22982
value@https://www.slatejs.org/main-e8e0520e642ae32de49e.js:1:188233
onChange@https://www.slatejs.org/main-e8e0520e642ae32de49e.js:1:187219
value@https://www.slatejs.org/main-e8e0520e642ae32de49e.js:1:116247
value/<@https://www.slatejs.org/main-e8e0520e642ae32de49e.js:1:116040
o@https://www.slatejs.org/main-e8e0520e642ae32de49e.js:22:163992
E/<@https://www.slatejs.org/main-e8e0520e642ae32de49e.js:22:164114
u@https://www.slatejs.org/main-e8e0520e642ae32de49e.js:22:167167


    in a
    in a
    in div
    in a
    in div
    in Styled(div)
    in div
    in a
    in a
    in div
    in a
    in a
    in a
    in a

Again, this does not happen if I do this in my Chromium instance.

Just filed a bug there: https://github.com/ianstormtaylor/slate/issues/2612

[non-Jedi]

@lampholder Given that a significant number of people have found their way to this issue after reproducing, could this issue get assigned a priority tag of some sort?

[ara4n]

i guess the reason it's not prioritised is because we've been unable to repro it, so it's hard to tell how many people are affected. but circumstantially it seems to be biting people a bunch, so will P1 it.

[cyphar]

I can also reproduce this issue (and have been experiencing it for the better part of a year, but kept forgetting to file an issue about it). Given the comment in ianstormtaylor/slate#2612 it seems to be a Linux+Firefox specific issue. Here is a GIF of the issue (I'm on openSUSE Tumbleweed with Firefox 65.0.1).

EDIT: Yup, I have dom.event.clipboardevents.enabled disabled.

[dms-cat]

This issue is caused by disabling dom.event.clipboardevents.enabled in about:config, which is a useful configuration change to enable pasting text (especially passwords) on sites which don't allow it.

The workaround is to simply flip the value of dom.event.clipboardevents.enabled to true (the default), but Riot should support pasting when this feature is disabled to avoid breaking this quality of life hack on other sites.

[aaronraimist]

@dms-cat Another option is to use https://addons.mozilla.org/en-US/firefox/addon/don-t-fuck-with-paste/ which should let you choose to only block those events on certain sites rather than disabling a fairly important feature across all sites. (yes I am the maintainer of that add-on on Firefox, but I'm also part of the matrix community)

[non-Jedi]

Thanks for tracking down the root problem @dms-cat (this has now become my favorite example of correlation \neq causation). Linux users are more likely to use password managers, and people using password managers are more likely to have dom.event.clipboardevents.enabled disabled (I myself had entirely forgotten about changing this setting) rather than this bug being due to some special combination of Riot, firefox, and linux.

To the Riot devs, given the above, is this a won't-fix or not actually considered a bug or something?

[t3chguy]

Is this still an issue for you in the new composer?

[absorber]

For me it appears not to be an issue anymore, and I have dom.event.clipboardevents.enabled set to false.

This is on FF 74.0 (64-bit) under Ubuntu 18.04.4