Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Middle button pastes the wrong selection #98

Open
ojwb opened this issue Apr 10, 2019 · 8 comments
Open

Middle button pastes the wrong selection #98

ojwb opened this issue Apr 10, 2019 · 8 comments

Comments

@ojwb
Copy link

ojwb commented Apr 10, 2019

The middle mouse button seems to paste from the clipboard (i.e. it does the same thing as Ctrl+V), rather than pasting the primary selection like it ought to.

To reproduce, run this in a terminal to set the X selections:

for s in primary secondary clipboard ; do printf $s|xclip -selection $s ; done

Then click the middle mouse button in the "Send a message" text entry in the Revolt window.

This pastes clipboard. If you try it in other apps (e.g. firefox, pluma text editor, MATE terminal, libreoffice, rhythmbox) you get primary.

This may seem fairly minor, but if you're a habitual middle-click paste user it likely means that sooner or later you're going to paste something you really didn't intend to into a chat window.

@xhess
Copy link

xhess commented Apr 22, 2020

This issue is still around and it is bothering me a lot. It is really annoying to paste the wrong stuff and then have to go back and do a copy using either the context menu or Ctrl+c and switch to revolt and paste it using the keyboard or the context menu.

@sumpfralle
Copy link

Same for me: it is surprising and a little bit dangerous (recently I almost send a message containing a password, that I just copied from my local password manager into the primary selection).

Just for adding a few more words of explanation: I accidentally opened a bug report for this issue against riot (mis-memorizing, that it also happens in a browser session): element-hq/element-web#14430. But it is not a riot issue - it only happens in revolt.

It would be great, if revolt would not override the default desktop behavior here.

Anyway: thank you for this useful application!

@ojwb
Copy link
Author

ojwb commented Jul 14, 2020

I wondered if this might be a webkit issue rather than something revolt-specific, but testing my above example with midori (a webkit-based web browser) gives me "primary" so this does seem to be specific to revolt.

@sumpfralle
Copy link

Just for sake of details: the issue seems to exist only for the text input widget for messages. Other input fields (e.g. the "room name" in the "room settings" window) use the primary selection when using the middle mouse button (as it is expected everywhere).

I looked through revolt's source code for keywords like clipboard, primary, selection and paste. But I found no indication, that revolt would do anything special.

Maybe it really is some weird interaction between elements/riot and revolt that is only exposed for the message input field?

@Marenz
Copy link

Marenz commented Jul 8, 2022

Same for me: it is surprising and a little bit dangerous (recently I almost send a message containing a password, that I just copied from my local password manager into the primary selection).

Yep, same issues. And it is super annoying that you need to paste/copy it somewhere else first now..

@Marenz
Copy link

Marenz commented Jul 8, 2022

But it wasn't always present, this changed for me about 1 or 2 months ago..

[Edit] but maybe I used the web version before, wrapped in a native-browser, not sure..

@Marenz
Copy link

Marenz commented Jul 8, 2022

I tried a version from 2018 and the problem still persists.

@Marenz
Copy link

Marenz commented Jul 8, 2022

I looked through various text field inputs and found that it works for all of them but the chat input.
The difference: All of the ones that work are <input..> based elements, whereas the text input is a <div> field

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants