You are not logged in.
Hi Archlinux community!
Since recently (maybe a few months), I'm not able to paste from clipboard to chromium anymore.
Interestingly, the issue arose about the same time on my home PC (Archlinux, Wayland, Sway) and my work PC (Ubuntu 16.04, X11, i3), so about the only common denominator seems to be the browser: chromium.
Pasting into other applications (like neovim, firefox or gedit) also seems to work for the most part (didn't test too intensely).
However, no matter how much I google for the issue, it seems I'm the only one facing this ![]()
I don't recall changing anything and on either system and I used to be able to copy from clipboard to chromium via CTRL-SHIFT-v (paste raw) without any issues before.
Does anyone have the same issue or even better: A solution or a good way to debug?
Thanks in advance!
Offline
While I can't really help you, just a guess.
You mentioned you have the problem on multiple devices with very different configurations, but it is an uncommon issue for anyone else. So I would think that most likely there is an issue with your configuration of the browser and you most likely have sync between all of them enabled.
The first area I would check out are add-ons, could you please launch your browser with 'chromium --disable-extensions' and see if the issue still persists? If fixed disable each extension one by one to figure out which one is causing it.
If this did not solve the issue logout of your account and delete all application data. Does it fix it? If yes there is some bad setting, but I can't tell you what. Might require some searching.
If by now the issue still persists I would expect some package to cause it. Although I would expect widespread reports then, but I wouldn't dismiss this option yet.
Offline
Hi Swiggles,
thanks for your answer!
I forgot to tell in my post, but I had already tried this as well (move ~/.config/chromium to rule out settings and extensions) at my work PC.
To be absolutely sure, I repeated the test on my home PC right now, but unfortunately, the effect is still the same: I can't paste from clipboard ![]()
I think I found something interesting while testing, though: It seems that - at least on my home PC - pasting in chromium works for things I copy from within chromium.
Do you have any other idea what I could try? Or is it time to file an upstream bug?
Best regards!
Offline
Pasting to the url bar, text forms or everywhere?
Did you try X11 on Archlinux?
Is the primary selection buffer (middle mouse button) affected as well?
Do the IBM shortcuts (ctrl+ins, shift+ins) work?
Do you run any kind of clipboard manager?
Online
Hi seth,
> Pasting to the url bar, text forms or everywhere?
everywhere, although login- and password-fields are most important to me.
> Did you try X11 on Archlinux?
Not yet, I currently don't have an X11 window manager installed.
> Is the primary selection buffer (middle mouse button) affected as well?
No, the primary selection seems to work for the most part. I say "for the most part" because it sometimes acts up, but in general, it works.
> Do the IBM shortcuts (ctrl+ins, shift+ins) work?
I've never heard of ctrl+ins... What should that one do? shift-ins also seems to only insert things I copied from inside chromium (same as ctrl-shift-v).
> Do you run any kind of clipboard manager?
No.
Thanks for your help and best regards!
Offline
ctrl+ins / shift+ins is copy paste as originally drafted by IBM (before MS figured it to be very smart to make ctrl+c the copy shortcut…)
Try X11 on arch to rule out the possibility that we're dealing w/ different bugs here (1. wayland, 2. ubuntu)
Since the primary selection buffer works and you can copy inside chromium, my money would be on some sway/i3wm config that kicks in when you focus chromium, so make your X11 test openbox ;-)
Online
Hi seth,
thanks for all your time and support!
I installed openbox and xorg-xinit and xclip, which replaced my installation of wl-clipboard-x11.
Then I started openbox via startx, opened chromium and a terminal and entered:
echo -n 'hello' | xclip -i -selection clipboard -l 1 -verbose
Then I tried to paste into chromium via ctrl-shift-v. No text was inserted, but the formerly blocked xclip exited.
Next, I started an nvim instance and tried to fill the clipboard ("+ buffer) from there and paste into chromium. That worked!
So I replaced xclip with wl-clipboard-x11 again, logged out of openbox and started sway again. There, I repeated the same test for Wayland:
wl-copy -o -f <<< hello
Again, no luck.
Then I tried via nvim and that worked again!
It seems that nvim is using xclip / wl-clipboard-x11 correctly where I am doing something wrong. Now to find out what that could be...
Offline
Same here, drop "-l1"…
Edit: -l4 works
Last edited by seth (2019-09-02 15:31:58)
Online
Under Wayland, dropping the -o (--paste-once) also works:
wl-copy -f "hello"
This let's me paste "hello" into chromium as often as I wish, but the wl-copy process (obviously) never exits, so it's no use for my script which feeds a login and password into wl-copy.
My current hypothesis is that chromium reads the clipboard multiple times before actually inserting the content, but after the first iteration (using --paste-once for wl-copy or -loops 1 for xclip) the buffer is empty.
seth, do you agree? Or do you see a different possible cause?
Last edited by the_isz (2019-09-02 15:54:32)
Offline
No, my reading as well.
What is that script? Why is it important to terminate xclip after 1 loop instead of keeping it up until sth. else (another xclip instance) picks the buffer?
Online
Hi seth,
What is that script?
the full workflow (triggered by a keybind) goes like this:
Open a terminal
Show all websites/services I have stored a password for, let me choose one via fzf
Call GNU 'pass' with the service name once to get the login, pipe to xclip/wl-copy and block until I have pasted it into the website
Call 'pass' again with the service name to get the password, pipe to xclip/wl-copy and block until I have pasted it into the website
Clear the clipboard for security reasons (both xclip and wl-copy do this automtically with their -loops/--paste-once options)
Why is it important to terminate xclip after 1 loop instead of keeping it up until sth. else (another xclip instance) picks the buffer?
Apart from the workflow/security reasons depicted above: How would you make sure you don't clutter your system with xclip/wl-copy instances? Do they somehow kill each other if more than one is running?
Offline
Upstream bug report for reference:
Offline
xclip terminates as soon as somethingelse™ claims the same selection buffer.
You're aware that chrome has a PW manager that does not copy sensitive data to the clipboard?
Though I guess this is a cross-browser approach.
And of course it defeats using a clipboard manager as well.…
Online
xclip terminates as soon as somethingelse™ claims the same selection buffer.
OK, that makes sense. Now it's just the workflow and security concerns of my script that speak against this approach ![]()
You're aware that chrome has a PW manager that does not copy sensitive data to the clipboard?
Though I guess this is a cross-browser approach.
It is even a cross-application approach (can paste into other applications) and I also store passwords with 'pass' that I don't even use on my computer at all.
Although I sure don't do everything I could to secure my privacy, I'm a fan of not keeping all my information in one place.
Google already has my contacts and my browser history, but they at least don't have my emails. And neither google nor my email provider have my passwords.
This lets me sleep a little easier ![]()
Again, thanks for all your support and time, seth, you really helped me a lot!
Offline