Bart Massey tried to get people interested in fixing the definitions
of cut/copy/paste handling in X a couple years ago, but couldn't get
enough people interested in helping solve the problem.  Notes from his
talk at the X Developer's Conference:
http://www.x.org/wiki/XDC2007Notes#head-32e40ea8e2174e26306aeae8e2f7bb5d99f0ec03
http://www.x.org/wiki/CutAndPaste

I think it is really time Xorg people get on this. There would be benefits for all linux users, just look at the launchpad bugtrackong page... Allow me to repost a possible implementation :

a) 100K web page (with images) gets copied in firefox
b) the clipboard acquires right away all the TARGETs the source (firefox) supports (text/plain, text/html, image/jpg, ...) 
c) the clipboard copies everything on ram or on disk
d) you can quit the source, everything is in the clipboard, with exactly the same TARGETs...

Maybe b) could be delayed until the source quits ? Is this feasible ?? 

OK if it is a large page/image, ask the user before mmap'ing 1Gb to ram but for nowadays what does it cost to keep 100K of html, the same content but for text, and another tabular data version for spreadsheet etc.

Maybe restrict all this for a localhost X11 connection ?

Any news about the status of this bug? This bug has been bugging me since the first week I started using Linux (in 2007). It's now 2010 and the bug still annoys me everytime I'm using Linux. I even switched from Linux to Mac OS X as my primary operating system, only because of the bugs in X. Since 2007 I used Linux as my primary operating system, but a few months ago I was so frustrated about the bugs in X that I went out and bought a MacBook. From now on Mac OS X is my primary operating system, untill the 16 year old bugs in X finally get fixed.

This bug has been annoying a lot of people for years. Look at all of those bug reports and comments at Launchpad and other bug reporting systems. People keep on complaining, because they loose their data when they put something on the clipboard and then close the application. Please, finally fix this bug.

As this bug is confirmed to be so many years old, I think it might be a good idea to raise the priority a little. Not highest, because it's not a security problem, but I should be fixed way before many other "medium" bugs.

Of courxe this bug should be of the highest priority. This bug causes data loss time after time, because people put something on the clipboard and then close the source before they've pasted the contents of the clipboard. A bug which causes data loss is the most critical kind of bug.

On Tue, Feb 23, 2010 at 10:15:46AM -0800, bugzilla-daemon@freedesktop.org wrote:
> Tralalalala <skabtrebge@hotmail.com> changed:
> 
>            What    |Removed                     |Added
> ----------------------------------------------------------------------------
>                  CC|                            |skabtrebge@hotmail.com
>            Severity|normal                      |critical
>            Priority|medium                      |highest
> 
> 
> 
> 
> --- Comment #5 from Tralalalala <skabtrebge@hotmail.com>  2010-02-23 10:15:45 PST ---
> Of courxe this bug should be of the highest priority. This bug causes data loss
> time after time, because people put something on the clipboard and then close
> the source before they've pasted the contents of the clipboard. A bug which
> causes data loss is the most critical kind of bug.

This is a design flaw, rather than a bug: if you close the application
you've copied data from, then the data will be unavailable, as X -- by
design -- does not store the data.  This seems like an entirely separate
bug.

What do you mean by "separate" ?

Because as far as I've understood the debate, people from Ubuntu seem to say
that this task should be the responsability of X, not of the OS him-self.

Currently, some Apps are working as workarround, but they are not as
efficient as most people expect the clipboard to be. So that's why the bug
have been openned here.

This bug is really old on the Ubuntu launchpad, and I think you might found
even older repports on some other distros. It has only been openned here
recently because I took all those years to figure out what part of the
system was in fault: X.

You can name it a design flaw, but I think it really a major one for the end
users, specially since the all the repports are so old now.

I think in terms of "fixing" this flaw, we need to be very careful.  We need to design it out thoroughly so that we're not "fixing" it down the road.  I'd like to think of it like designing the specs for ssl.

It has to have following:

1.  Cut/Copy without needing to keep the source open to then paste it
2.  Disable global selection based copy because that just messes people up who try to delete some text by highlighting it first.  Individual applications can still implement it if they wish.
3.  To cut/copy and then paste has to be explicit using the keyboard shortcuts like ctrl+c, ctrl+x, and ctrl+v.
4.  It can also be done using cut, copy, and paste in a menu like under edit like it is in Windows and OS X.
5.  Keyboard shortcuts can be overridden to do something else if the application wants to.  An example is putty in windows where it does have selection based copy and right clicking does a paste.  The keyboard shortcuts are then overridden to have other functions or disabled entirely in putty and instead are used for terminal commands like ctrl+c forces the current program you're running in there to quit.
6.  The api for cut, copy, and paste will by default use the standard keyboard shortcuts but allow the author of the application to disable that portion of it and allow them to specify another method to do the cut, copy, and paste.  This will keep developers that are coming from windows and OS X happy since they won't have to do much to get it working.

Copying the data to the clipboard:

1.  The clipboard in Xorg will specify a maximum size that can be used for the clipboard.
2.  When data is sent to the clipboard, it will include what kind of data it is, and the program it came from.  This is so that with certain kinds of data, there can be special instructions in dealing with it.  For example copying a file doesn't require you copy the whole file into memory, but merely the location of where the file is and the name of the file.  It can also include special instructions that the program has to remain open for the data to remain in the clipboard.
3.  The clipboard will send an acknowledgment back it now has the data.
4.  That data will have a unique id assigned to it.
5.  If the data is under the size limit, it will send that acknowledgment as usual.
6.  If the data is over the size limit, it will send an acknowledgment to the program that says the program has to confirm it wants the clipboard to store that much data.  The program can do this automatically if it expects to be copying large chunks of data into the clipboard, or it can do it manually by asking the user to confirm it.
7.  Once the clipboard has that confirmation from the program, it will attempt to store the data it is asked to.
8.  If there is still a problem with storing that much data, it will send an acknowledgment with the reasons why it can't store that much data, such as not enough ram.
9.  The program can also truncate the data if it is over the limit when copying it to the clipboard as well.

Copying data from the clipboard back into the same program or another program:

1.  Using the api for pasting the data, the clipboard will automatically empty itself if the data had used the cut method instead of copy method to be copied into the clipboard.
2.  If the data had been copied to the clipboard instead of using cut, then it will remain in the clipboard after being pasted.  The exception being is if its a certain type that specifies the program that the data came from has to remain open in order to paste it.
3.  When the api for pasting the data is called, it will automatically know the unique id that was assigned to that data without the programmer having to specify it.
4.  The clipboard will keep track of data copied into it and all management associated with it.  It will handle only one piece of data at a time.  This can be expanded at a later time if needed to support multiple pieces of data into the clipboard.
5.  If a program has copied a large amount of data into the clipboard that was over the initial limit allowed and acknowledged it wanted that data copied, upon the exit of that program, it is responsible for checking if it still has data in the clipboard.  The clipboard because it kept the name of the program that copied the data into it, the api for this check will not require the author of the program to pass that data, it will automatically be passed while calling the api.  The clipboard when this check is done will return the data type and the size of it.  If there is data that exists in the clipboard that was over the limit allowed, the program will then ask the user if they want to remove it from the clipboard or keep it.  The program can also instead automatically remove this data so it doesn't have to ask every time should the above conditions be true.  This check that is done will only be for data that was over the limit, not for any data that was under the limit.

Program example with putty:

1.  Changes the clipboard keyboard shortcuts so they are used for linux type terminal commands.
2.  Copy is done via doing a highlight of selection of text.
3.  Paste is done via doing a right click inside the putty window.
4.  Putty does not use cut at all.

Program example with adobe audition:

1.  Does cut, copy and paste as normal.
2.  When exiting, it checks if there is data it copied to the clipboard that was over the limit allowed.
3.  If there is, it asks the user if they want to empty the clipboard or not with yes being highlighted by default.

If you want to create a spec based on the above, feel free to.  It should be on a wiki so that we can all collaborate on it.

LOL.

This is a great bug.  I too every so often experience the pain that comes with closing an app before I've had a chance to paste from it.

I love the comments, especially the linked rant.

A few things to note, though:

  * If you run a clipboard manager such as http://parcellite.sourceforge.net/ it will save the clipboard when it sees a copy act.  In fact, it will save a complete history of all copy acts; something that AFAIK neither Mac or Windows does for you these days.  (My original 128K Mac actually had an app that would page back through previously-clipped stuff, but I haven't spotted it in a while.  Maybe it's still around.)  Thus, no changes to applications or X are needed to remedy this particular design issue.  Just get a tool.

  * Once you've fixed this little problem, X cut-and-paste will still totally suck.  Almost no interoperability between apps for anything other than unformatted text, almost no support for most media types, complete lack of uniformity in user interface beyond the most basic functions, etc, etc.

  * Even specifying cut-and-paste behavior that makes even 80% of X users happy is really, really hard.  I think so, anyhow, because I and a whole classroom full of smart people once burned 2.5 months working on it without winning.  (Of course, maybe I and they are just fail.)  Once you've specified it, you face the question of how to make every X app, toolkit etc in existence conformant.

Let me be clear.  I would *love* to see the major GUI toolkit builders get together and iron out a proper X cut-and-paste specification, then jointly push it into their toolkits and UI guidelines.  I would be happy to help how I could with such a project.  I think it's probably feasible, albeit on a several-years' timescale.  It took us 10 years to get XCB mainstreamed.  It's still not done.  IMHO mainstreaming XCB was much easier than mainstreaming new cut-and-paste will be.

However, filing a bug against X cut-and-paste at freedesktop.org and insisting that it be raised to highest priority is just comical.  Fixing X doesn't work that way.  Even if many Ubuntu Launchpad folks want it to.  If you want X cut-and-paste issues fixed, pitch in and help.  The specification in the previous comment isn't anywhere near done, obviously, but it at least shows the right attitude.

I want to close this bug, but none of the standard resolutions work for me.  I wish there was a WTF resolution.  In the meantime, I'll just leave it open, with an appropriate priority and severity.

Ok, but, considering that I (and most of us) doesn't know how to program and
how C works, how can I help ?

Because if you wait that someone learn C, learn X, then make a patch, we
will never see this problem solved, never.

Which is why you need to first start designing how it should work before any programmer touches it.  Once that specification is done, then the development work can begin.  You cannot just go in and start programming without doing planning.  It's like building a house without blueprints.

I know this is not an easy route, but it has to be done.  Yes all X applications will have to conform to this once the initial work is done.  So will all tool kits.  That's a fact and shouldn't stop us from working on this.  But to make that easier, drop support for tool kits that are considered legacy.  Then you don't have to worry about them.  Just get the initial X code base working with it.

But maybe X itself should be stripped down.  No X applications, etc.  Just the ability to create DE's that run on top of X while using X's ability to do the gui side of things.  I can see why google when creating android chose to develop something that replaces X completely.

Bart Massey, may I ask what stopped your class from working on this after 2 and a half months?  What was the issue that stopped development?

It took 10 years to get XCB mainstream?  You need to come up with better names cuz I had to google it to find out what it was, but anyways.  Isn't there deadlines/milestones in terms of getting features in there?  If a feature can't be finished in time, it is dropped and set to be put in for the next revision.  Or does every single feature need to be put in there?

This is just how selections work.  If the application is closed, there's nobody 
to ask for the data.  If you want this to work right, use a clipboard manager.

Most users don't want this selection based clipboard.  But if no one is gonna fix it for xorg, off I go to submit it gets implemented in wayland.

There's a very easy solution for this bug: Buy a Mac, so you can use Mac OS X. Mac OS X just works.

Stop complaining about users not wanting selection-based copying.  It has no negative impact if you don't use it, and users most likely won't notice it.

Let me shed some light on this (since there also seem to be so many references to this bug everywhere).

Selected text gets copied to PRIMARY, and get pasted *only* by pressing mouse2.
If you press ctrl+c, whatever is selected is copied to CLIPBOARD.  Only pressing ctrl+v (or selecting "copy" from some menu) will get CLIPBOARD pasted.
PRIMARY and CLIPBOARD never interact; ever!  So if you don't want selection-based copying, just don't press m2, and you're done, there's no need to change anything, and it doesn't affect the usage of CLIPBOARD.

I use both mouse buttons, so yes it does effect me.

Just admit this was an awful design.  Besides, they've refused to fix it.

That's why it's been submitted to wayland instead.  You can stay behind on old tech while the rest of us welcome the modern era.

@Hugo:
Fuck off, you moron! Not pressing that button worked 15 years ago when the scroll wheel wasn't yet invented and the middle button was the same kind of button as the left and the right button. Nowadays mice have scroll wheels and it is very common to accidentally press that scroll wheel while scrolling. So you're scrolling through a text document, you accidentally press the scroll wheel a little bit too hard and some text is inserted in your document.

People, please stop using this crap. Linux is just utter crap on the desktop and will never succeed. I can't understand people still use it. Buy a Mac or install Windows 7. Linux is completely useless and will always be completely useless.

I suppose the reason why this won't be fixed is because xorg is being replaced by wayland.  Let's hope that wayland fixes it then.

Soon enough xorg will be obselete.

Is there any reason why this ticket is marked as INVALID? Even if this will still need a while I think we should not stop working on it.


Maybe another possible solution would be to implement this as an optional API that doesn't require to drop support for legacy applications (at least not in the near future). Developers can make use of this API for copy/cut/paste in their applications and old applications will still act in the current way - either a clipboard manager will take care of this or the clipboard gets lost.

(In reply to sworddragon2 from comment #19)
> Is there any reason why this ticket is marked as INVALID?

Because it's simply a flame war and disagreement with the current design.

Reopening the bug has a 0% chance of getting anyone to work on it, and is
unnecessary should someone have a concrete proposal to present - new feature
work is done via discussion & patch review on the mailing list, not endless 
bug threads.