Skip to content
This repository has been archived by the owner on Mar 12, 2021. It is now read-only.

copy & paste #335

Open
burdges opened this issue Mar 13, 2018 · 7 comments
Open

copy & paste #335

burdges opened this issue Mar 13, 2018 · 7 comments

Comments

@burdges
Copy link

burdges commented Mar 13, 2018

It appears Tor browser keeps a separate copy & paste buffer from the rest of the system, which makes
Tor browser basically unusable. If you attempt to drag text from Torbrowser, then the text appears as a black square. It appears as a square containing the text if you drag text from another application.

A shell run in the Torborwser-launcher sandbox uses the system copy & paste buffer, btw. Also, there are sandboxed applications like Chromium that correctly use the system copy & paste buffer.

@burdges
Copy link
Author

burdges commented Mar 13, 2018

Actually it started happening in Chromium after restarting Chromium, so I rebooted which seemingly fixed it. It's likely just hiccups floating down the stream from debian

@burdges burdges closed this as completed Mar 13, 2018
@burdges
Copy link
Author

burdges commented Mar 17, 2018

I now think cut & paste simply dies after some time, without any connection to package upgrades.

@burdges burdges reopened this Mar 17, 2018
@burdges
Copy link
Author

burdges commented Mar 17, 2018

Just to clarify, the copy & paste works within Torbrowser and within Gnome, etc., but Torbrowser and Gnome have seperate copy & paste buffers, which makes it mostly useless. Also, all obvious copy & paste settings from FireFox, like clipboard.autocopy, remain in their default state, but given the problem has occurred in Chromium the problem likely occurs outside the application.

@burdges
Copy link
Author

burdges commented Mar 18, 2018

It's likely the Xpra clipboard bug causes this, so presumably Xpra must be updated again for recent browsers.

@ghost
Copy link

ghost commented Mar 23, 2018

Subgraph is switching to an entirely new concept so this current iteration of what Subgraph OS will cease to be in the near future. I do not expect that the SGOS devs are going to be doing anymore bug fixes for the issues. See their announcement here: https://twitter.com/subgraph/status/969933763777097728

It is kind of unfortunate for those of us who liked what they were building with the Alpha as were stuck with a unstable OS that wont get fixes and now have to wait probably quite awhile to see what they are building next.

Perhaps @dma can chime in on whether we can expect any further updates here? Maybe even post something on the SGOS website so people do not expect further updates if they wont be coming.

@burdges
Copy link
Author

burdges commented Mar 23, 2018

Interesting. I should remain with a Debian derivative myself probably, or maybe Guix/Nix, so I'll migrate to https://wiki.debian.org/grsecurity presumably. We'll see what shakes out of course. :)

I've missed any conversations about Oz vs whatever they're doing next, but overall Xrpa seemingly brings a huge usability hit, so no complaints about seeing it disappear.

@burdges
Copy link
Author

burdges commented Mar 25, 2018

I replaced the environment read of XPRA_CLIPBOARD_LIMIT with 10000000 in /usr/lib/python2.7/dist-packages/xpra/server/soruce.py to see if that fixes it.. and disabling the clipboard happens in the same file, so you could disable it there too.

It's supposedly a per-second limit though, so really this sounds like an xpra bug that they disable the clipboard permanently.

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

No branches or pull requests

1 participant