MASTER Copy-Paste doesn't work if the source is closed before the paste

Reported by Arandonohue on 2004-12-20
This bug affects 337 people
Affects Status Importance Assigned to Milestone
AbiWord
Confirmed
Medium
ChmSee
Unknown
Unknown
Chromium Browser
Unknown
Unknown
Eclipse
Unknown
Unknown
Empathy
Unknown
Medium
Epiphany
Invalid
Medium
GTK+
Confirmed
Medium
GnuCash
Fix Released
Medium
Inkscape
Low
Unassigned
KDE Utilities
New
Undecided
Unassigned
LibreOffice Productivity Suite
Confirmed
Medium
OpenOffice
Confirmed
Unknown
Qt
New
Undecided
Unassigned
Webkit
Fix Released
Medium
X.Org X server
Invalid
High
XULRunner
Fix Released
Medium
Xournal
New
Undecided
Unassigned
gnome-utils
New
Undecided
Unassigned
kdelibs
New
Undecided
Unassigned
mousepad
New
Undecided
Unassigned
tomboy
New
Medium
Ubuntu
Wishlist
Unassigned
Declined for Dapper by Chris Coulson
Declined for Hardy by Chris Coulson
Declined for Intrepid by Chris Coulson
Declined for Jaunty by Chris Coulson
Declined for Karmic by Chris Coulson
Declined for Lucid by Chris Coulson
Declined for Maverick by Sebastien Bacher

Bug Description

===+++ _____________________ ! ALL USERS ! _____________________ +++===
===+++ READ THIS BEFORE MAKING A COMMENT OR MODIFICATION +++===

IMPORTANT 1: Please see the WORKAROUND a few lines below.

IMPORTANT 2: Please don't post any "me too message"; use the "Does this bug affect you?" feature you can find a bit above this bug description on Launchpad.

IMPORTANT 3: Do not post anything if you haven't read all comments to verify that your point hasn't been made. If you feel tempted to stop reading because there are too many messages, that is a strong indicator that you shouldn't add even more comments. Developers have a tough time to find anything if you post redundant stuff. So please abstain from doing that.

*** WORKAROUND ***
---------------------------
Install diodon, klipper, glipper, parcellite or xfce4-clipman
--------------------------------------------

*** EXPLANATION OF THE BUG ***
When I copy (Ctrl + C, or right click and "Copy") text from somewhere and after that close the program where it is, the clipboard gets empty.

Steps to reproduce in gedit :
1. Pick any text field that supports copying, copy some text.
2. Paste into any other text field.
3. It works.
4. Close the source window or program.
5. Paste now does nothing.

This bug will happen in any application that doesn't comply with the clipboard specification from FreeDesktop.
http://www.freedesktop.org/wiki/ClipboardManager

There was also previous considerations about improving xserver-xorg clipboard, which would reduce adaptation work from upstream projects to comply with the specification.
Xorg : https://bugs.freedesktop.org/show_bug.cgi?id=25220
http://www.x.org/wiki/CutAndPaste
A related proposal is to implement it in Wayland: https://bugs.launchpad.net/ubuntu/+source/wayland/+bug/865885

******** Actual Status : ********
----- Not fixed : ------
OpenOffice : http://www.openoffice.org/issues/show_bug.cgi?id=63092
LibreOffice : https://www.libreoffice.org/bugzilla/show_bug.cgi?id=48783
GIMP | GTK+ : https://bugzilla.gnome.org/show_bug.cgi?id=510204
Gnucash : http://bugzilla.gnome.org/show_bug.cgi?id=510205
Inkscape : This bug.
Blender : https://developer.blender.org/T38674

++++ Fixed : +++++
Firefox, Thunderbird, Sunbird (Xulrunner) : Fixed in 1.9.3 trunk https://bugzilla.mozilla.org/show_bug.cgi?id=311340
Evolution : Fixed in 2.29 http://bugzilla.gnome.org/show_bug.cgi?id=258374
Chromium : http://code.google.com/p/chromium/issues/detail?id=32291
Pidgin : Fixed
Gedit : Fixed
Most Gnome apps, Fixed
*************************************

Related branches

Sebastien Bacher (seb128) wrote :

anybody with some knowledge about the internals of the copy/paste system ?

Daniel Stone (daniels) wrote :

I believe the reporter has just discovered how X's clipboard mechanism works;
there is no persistent store. When you click 'copy', the source window simply
announces that it is claiming the CLIPBOARD selection (others to claim include
PRIMARY and SECONDARY). When you click 'paste', that window is queried for the
contents of the selection. If the window[0] does not exist, it cannot be
queried, and thus you cannot paste.

[0]: Not window as such, but connection to the X server. As soon as that
instance has no connection, it's out.

Since gnome desktop that firefox attempts to blend with on linux uses the
freedesktop specs for clipboard management, anything copied from firefox is lost
when firefox is closed as firefox does not follow these specifications:
http://www.freedesktop.org/wiki/Standards_2fclipboards_2dspec

in other applications copying something and closing the application does not
cause the copied content to be lost (this clipboard manager was implemented in
gnome 2.12)

*** Bug 312485 has been marked as a duplicate of this bug. ***

I'd like to bring this to the attention of the necessary developers so we can get this in - it's annoying having Firefox not interact properly with gnome-clipboard-daemon (or anything else for that matter).

*** Bug 330704 has been marked as a duplicate of this bug. ***

I'm not sure I follow. We follow the spec at http://standards.freedesktop.org/clipboards-spec/clipboards-0.1.txt just fine -- the Ctrl-c key combination uses CLIPBOARD while mouse-highlight uses PRIMARY.

The behavior I observe in Mozilla is the same as the behavior I observe in Gnumeric and the Terminal thing that Fedora Core 4 ships with -- the CLIPBOARD is available until the app quits, but not after that.

So as far as I can tell, this bug is invalid -- it's demanding that we implement a specification that we already implement and implying that doing that will change what happens when the browser is shutdown (which looks like an unrelated issue to me).

What am I missing?

The problem from my perspective is that Firefox somehow bypasses gnome-clipboard-daemon which is used for ensuring that CLIPBOARD does exist after the program quits.

I guess it's a duplicate of Bug 23386. Someone should probably dupe one of these against the other.

Btw the Summary field of this bug is really invalid. AFAICS, gnome-clipboard-daemon is not a part of the Freedesktop.org specification.

One last thing (sorry for too many messages). I'm using GNOME and Cutting and Pasting from Gedit (as an example) works even after I quit it. However, I've just checked and I don't see any gnome-clipboard-daemon or -manager banary running or even existing on my system. However I've found out an announcement of GNOME 2.12 [1], which states that that version of GNOME is managing the clipboard in a new, much better, way. It also states that this feature is based on a freedesktop.org specification.

The summary of this bug should be changed to something more exact, but I'm not sure about to what. However, the developers of Mozilla may want to look at the list of clipboard-related links in freedesktop.org[2].

[1] http://www.gnome.org/~davyd/gnome-2-12/
[2] http://freedesktop.org/wiki/FindPage?action=titlesearch&value=clipboard

(one last message for now, I promise).
It's the link that is bad, not the summary. Someone please change the link to http://freedesktop.org/wiki/Standards_2fclipboard_2dmanager_2dspec

Also, please dupe Bug 23386 against this one.

could anybody apply the changes listed in my last comment, please?

I confirm this issue as well.

From Daniel Stone answer I understand that this is no bug but the common behaviour of the X clipboard?

Still I (perhaps not only me as I see that this "bug" is reported more than once (see #36165) ) find this behaviour quite strange.

Perhaps I will get used to it but does anybody know if there is a workaround for this issue?

Thanks in advance...

Andreas Lloyd (lloydinho) wrote :

Ubuntu QA guy Simon Law puts it like this:

"Thank you for your report.

This behaviour has always been the case and is a design feature of X11.

You are describing SELECTION and PRIMARY buffers. They were separate and have semantics that are both supported by major X applications. It is unlikely that this will change in the near future, even though more and more applications prefer exposing the PRIMARY buffer in their menu systems."

glipper is a good solution/work around:
http://www.gnomefiles.org/app.php/Glipper

Magnetizer (magnetizer) wrote :

Thanks Marcel :-)

I'll try

*** Bug 23386 has been marked as a duplicate of this bug. ***

Changing the URL and reassigning the bug to Toolkits/Widgets, as it seems more appropriate to go there.

Anyone know if a freedesktop clipboard fix will be in Firefox 3? Firefox sticks out like a sore thumb due to this issue and makes it look unpolished, even though it ships with many Linux distros. (there are multiple bugs in Ubuntu's Launchpad about this as well, if devs need more info: https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/21202 https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/69613
https://bugs.launchpad.net/bugs/81506 https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/90477 )

I don't think this bug should be considered an RFE anymore. It's much rather a major loss of functionality, IMO.

FWIW, even windows works this way (as in, once the source window is closed, the data is lost).

Having glipper as a dep would solve this though.

Alec Wright (alecjw) wrote :

Why should it work this way? Ok, it saves memory, but out of 1GB or so, a few bytes of text isn't going to do much. I think this bug should be confirmed and marked as wishlist

Andrey Andreev (narf) wrote :

No, windows does not work this way - I just tested it.

Alec Wright (alecjw) wrote :

Well in the grand scheme of things, how windows works is pretty irrelevant. This is ubuntu, which should work in the way that works best, not just the same way as windows.

Andrey Andreev (narf) wrote :

I agree on that and I've never said it should work this way just because Windows does.
I was just replying to Sarah Hobbs' comment.

Hi,

I want to solve this problem whether a bug or not..
Can anybody help me, I want to know where exactly this problem should be delt with.
I mean, which file in the source code contains the relevant code.

i also have this problem (Bug #11334)

is it possible to solve this problem on Ubuntu 8.04 ?

Chi (nickmacavoy) wrote :

This would have to be my number 1 "bug" in Ubuntu, I run into it several times a day and is at the top of my wishlist to Santa. I understand it's not bug, it's in fact working perfectly, it's just restrictive and a little frustrating.

Alec Wright (alecjw) wrote :

This bug definitely is valid, and confirmed by several people. It should probably be wishlist rather than medium though.

Since the URL field leads to a page that doesn't exist, I am pointing it to current location of Clipboard Manager specification:
http://freedesktop.org/wiki/Specifications/clipboard-manager-spec

Trisha: This bug is not about the Clipboard spec, which as B Zbarsky rightly pointed out, Firefox already implements, but rather the Clipboard *Manager* spec.

I have this bug too!

1960 called and want their copy&paste system back.

Windows 3.11 could do this 15+ years ago.

This bug pisses me off! Fix it!

Fred (eldmannen+launchpad) wrote :

This is an important bug, and its been 3-4 years since its been reported, and you still haven't fixed it.
Other operating systems have had the functionality for like 20 years.

Please fix this.

This annoys me a lot. I must use Epiphany or other browser, if you cant fix it.

Really? 3-4 years? Why has it not been fixed after so long a time?

Pedro Villavicencio (pedro) wrote :

Because probably nobody has the knowledge, time or is not interested to work on it? Comments like you're posting recently doesn't help at all, if you want to help to get this fixed you can work on a patch and submit it to the report, but please stop commenting with no useful information. thanks in advance.

This bug is _the_ most annoying bug for Firefox on Ubuntu. I'm hit my this bug at least once every week.

*** Bug 221183 has been marked as a duplicate of this bug. ***

I think there are case where it is very important to retain copy buffer : Have you ever tried to create a filter with a header in evolution ?
A natural way would be :
- Show source message
- Select and copy desired header
- Close window
- Go to Edit > Filters > New >
- Paste
Unfortunately, it doesn't work, because of what has been said above... I have to keep the window open, and once filter is created, go back to find it in order to close it...

But I thought selection buffer (X-managed) was different from copy-paste (WM managed)... but even CTRL-C doesn't retain clipboard...

It is my #1 wishlist/bugfix as I run into it very often... Worst, it seems to me that even if selection buffer worked that way, copy-paste used to behave as expected... maybe in my days of using windowmaker ?

Thanks for working so hard for us !

Guilhem (logik-free) wrote :

Found this from : http://www.vergenet.net/~conrad/software/xsel/
cut --
Make the selection contents persist in memory

Normally the X selection only exists as long as the program it was selected in is running. Further, some buggy applications tend to forget their selection text after a little while. If you run:

xsel --keep

after selecting some important text, xsel will copy the text into its own memory so you can paste it elsewhere even if the original program exits or crashes.
-- cut
If a simple/old program can do this, couldn't this be integrated in gnome window manager ??

Thanks

This bug is getting aged, and it is still not fixed, nor has there been any progress on it. It would be great if this was fixed for Firefox 3.0 final.

(In reply to comment #20)
> This bug is getting aged, and it is still not fixed, nor has there been any
> progress on it. It would be great if this was fixed for Firefox 3.0 final.

Don't expect it to happen for 3.0, I think it's feature complete already. Let's hope for the next major release.

JD (jacobdorne) wrote :

I can fix it if I use Glipper or Klipper (preferred) on KDE. Installing one of these makes everything better.

mindracer (dsartoros) wrote :

Hi this bug kills me especially when i copy things from firefox, especially when i want to copy a link fro mfirefox and close it to re-open it (because of flash bugs).

Please this is not a wishlist bug, this seems moderate, i cant believe this bug was reported two years ago and it still isnt fixed...

mindracer (dsartoros) wrote :

Sorry i just re-read and noticed its not an actual bug and why its a wishlist. This is a BIG wishlist, it gets quite annoying.. I understand how linux is meant to work, but when you work in an OS thats aiming to be a real alternative to MS and OSX, it would really help to get copy and paste to work even better! :)

Nick (morrownr) wrote :

I disagree that this bug should be rated as a WISHLIST bug. My opinion is that it should be rated as a CRITICAL bug.

This is a design bug!

It is darn hard to recommend this os when there are silly bugs such as this listed as features?!?

Pander (pander) wrote :

I also lost some data after hard work because of this bug. Beginners and advanced uses assume on a very basic functional level that this bug is not there. Hence the data loss risk while working is too high.

Please increase the importance and release a fix soon..

Michael Nagel (nailor) wrote :

i'd like to have this thing addressed, too. this "bug" can be very frustrating for users switching from windows and it's by far more convenient for beginner/intermediate/power-users to have this functionality, too. i can think of no use case where the current behavior brings an advantage.
i see that X is not something very dynamic and the X clipboard will probably not be changed soon. but (as suggested) glipper provides the needed functionality (and a whole lot more). i'd suggest to get glipper maintained, included in main and shipped installed with the default setup.

*** Bug 412782 has been marked as a duplicate of this bug. ***

Just because X has behaved this way forever doesn't make this user friendly behaviour.

Besides - it doesn't require new code - just include glipper by default and add it to the panel.

I've been using Linux for a while and it's still annoying when clipboard data is lost... I added glipper but it's buried in synaptic and then you have to add it to the panel (not even in add/remove... not that any user would know to look there)

Michael Nagel (nailor) wrote :

nota bene: parcellite should be preferred over glipper (unmaintained) right now.

Tralalalala (tralalalala) wrote :

Can this please be fixed?

On Tue, 2008-12-30 at 12:38 +0000, Patrick Roberts wrote:
> Can this please be fixed?
>

Comments like that don't help in any way to speed up the bug fixing
process.

See my comment here for a much longer comment:
https://bugs.launchpad.net/firefox/+bug/21202/comments/37

Sorry for kicking this thread with that previous comment, but in my opinion it's ridiculous there's still no working copy/paste function in Linux, after all those years. In my opinion it's way more important to have a working copy/paste function, instead of (for instance) some new way to notificate users. The current notifications already work, copy/paste doesn't work like it has to work. Let's first fix all of those bugs, instead of adding new features and improving thing that already work without problems.

When checking what happens to the clipboard content on exit [1], we can see that any xulrunner application clears the clipboard (or sets it to be empty). I hope this can help to pinpoint where the problem lies.

[1] eg. when running xclipboard to monitor successive contents, but under an environment that does mess by itself with the clipboard and selection, that is eg. plain fvwm, or kde 3.5 with klipper set not so sync clipboard and selection, and not to forbid empty clipboard

I was working on some article (in a web-based cms, sadly without autosave or drafts) and decided to save it on a usb pendrive in order to continue later on my friend's machine. So I copied the content, closed firefox, opened my editor... but couldn't paste it :/

The bug's importance should be raised, it causes *data loss* :/
Please, fix this issue.

I completely agree, MATi.

Why does it take so long to fix this bug? Why don't the developers see how important this is? It's just ridiculous this still doesn't work. Being able to copy / paste is one the basic features of an application and in my opinion those features have the highest priority to work on. After all those years this basic function still doesn't work in Firefox, but a lot of other features have been added in those years. In my opinion this is a wrong choice. Working on important basic features must have a much higher priority than working on all those features which are nice to have. Fix all those bugs first and introduce new features when those bugs are fixed.

This is not only a problem with Firefox. It seems to be a basic problem of open source projects. Looks like open source developers develop an application and keep on adding new features without first fixing existing bugs. I'm thinking about Gnomes Nautilus with its bugged list view (not being able to drag and drop a file into a folder when there are more items than fit on the screen).

Please, fix those bugs first and then start adding new features.

YAC - Yet Another Confirmation

... and yes, this bug is rather annoying one.

Kiki (mess110) wrote :

I think the problem is that the copy "buffer" if you want to call it like that is saved somewhere in the current program memory. When the program is closed the "buffer" is erased so there is no source to copy it from.

A possible fix would be allocating some memory for copy. But than again this might prove to be a really bad security flaw.

Please correct me if I am wrong. I just THINK this is how it works.

Tralalalala (tralalalala) wrote :

Yesterday my father wanted to log on to a website. He didn't know the password anymore, so he looked up this password in Evolution, copied the password, closed Evolution and tried to paste the password in Firefox. The paste function was greyed out and my father thought he had clicked on the wrong button, instead of the copy button. He opened Evolution again, copied the password from the e-mail, closed Evolution and tried to paste the password in Firefox. Again he was unable to paste the password and he really had no clue what was going on.

As I said before a working copy and paste function is one of the basic features of an operating system. This is something that has to work... always. A lot of people have lost already lost their work, because this basic function of an operating system still doesn't work. There are a lot of stories of people who type a long reply in an text editor and after more than one hour of work copy this reply, close the editor and try to paste it in Firefox to reply on a forum. All of the work is gone and there's no way to get it back. More than one hour of work is gone.

People don't want to loose hours of work, only because a basic feature of an operating system doesn't work. This is one of the reasons people go back to Windows or buy a Mac. On these operating systems copy / paste works the way it should work and they won't loose their work, because they closed the source.

If you want to be taken seriously, than implement a copy / paste function that works the way it should work. Otherwise people will always look at Ubuntu as an half-baked, amaturistic operating system.

It can't be that hard to implement, because Desktop Data Manager already makes it work the way it should. Take the source code of this application, take out all unneeded featues (screenshot utility and download manager) and implement it in Ubuntu. Problem solved.

Michael Nagel (nailor) wrote :

@comment 6:
in true unix history of having one tool to do one thing right i do not necessarily think it is a workaround to have a program dedicated to managing the clipboard.

however i think solid copy&paste is a feature everyone can expect to work out of the box. and because i think it is highly unlikely to get this supported in X directly anytime soon i think the right thing to do is to include a clipboard manager (be it glipper or parcellite) in the default distribution. maybe in a modified version to show no task list icon (and thus only exposing the basic "copy and paste just works"-behavior but not the advanced history&co options).

somewhere i read a complain against clipboard manager where it blocks a feature in gimp that responds differently to paste-requests from different applications (thus exporting all pixel data when pasting to a third party application and doing some internal speed-optimized pointer logic when simply pasting to a different layer within gimp). this is a valid point but it nowhere justifies to ship such a broken copy&paste for most use cases. and if this behavior is so critical gimp may just provide two copy-methods one for the data and one for the pointer -- and export the more sane one to the ctrl-c shortcut.

--> we should really try to get a clipboard manager in the default distribution for karmic. the importance of this bug should be raised to... at least something above "normal" imho.

Tralalalala (tralalalala) wrote :

@Michael Nagel:
I've tried Glipper, Parcellite and Desktop Data Manager. In my opinion Glipper and Percellite just don't work. Both of them only support text, I've had problems with these applications not starting when booting the system, after installing these applications the copy / paste function of OpenOffice.org stopped working properly.

I'm using Desktop Data Manager for months now and I haven't had any problems. It not only supports text, but also images. I haven't had any problems with this application. It always starts and copy / paste just works, always.

"maybe in a modified version to show no task list icon (and thus only exposing the basic "copy and paste just works"-behavior but not the advanced history&co options)."

I'd really like to see a stripped down version of Desktop Data Manager to be included in the default distribution.

"--> we should really try to get a clipboard manager in the default distribution for karmic. the importance of this bug should be raised to... at least something above "normal" imho."

I completely agree.

I agree. but this is more of a workaround. the copy paste thing should just
work! maybe include it in the next dist. karmic may be promising :P

I had a conversation with Philipp Kern recently and he basically shares our opinion. To get it in the default release we should:

- collect all known/possible regressions (like c&p of binary data, some magic gimp seems to do, ...)
- find someone from the official canonical team to support this

probably a blueprint summing up the reason why this change is needed together with these two points is the way to go.

LimCore (limcore) on 2009-06-02
description: updated
tags: added: epicfail
Tralalalala (tralalalala) wrote :

"This bug is an Epic Fail, because it's 2009 and still we do not *fully* support trivial things like copy/paste."

I couldn't agree more. I always say: "How can we ever solve bug number one if Ubuntu (or more general "Linux") can't even remember an image I placed on the clipboard two seconds ago?"

"Fortunately this works well in KDE."

Is this true? I know KDE includes Klipper (KDE-version of Glipper) by default. Glipper only supports text. Correct me if I'm wrong, but I assume KDE's copy and paste function also supports text only. So, if you're running Firefox and you copy a picture (for instance the launchpad logo on the top of this page), you close Firefox, start The GIMP and try to paste the logo from the clipboard the clipboard is empty.

I don't use KDE, so I don't know how it works exactly. I only know Klipper is included by default and I assume in KDE you're left with the same functionality as when running GNOME with Glipper installed. This still isn't a WORKING copy and paste function, but it's a HALF WORKING workaround.

Martin Albisetti (beuno) on 2009-06-03
tags: removed: epicfail
Mat Tomaszewski (mat.t.) wrote :

I cannot reproduce this bug in 9.04. Can someone else reproduce that in Jaunty, and if so, what are the steps?

Tralalalala (tralalalala) wrote :

I'm not going to explain how to reproduce this bug again. I've done this before for about 452 times. How many times do I have to explain how to reproduce this bug? I can't imagine people keep on asking how to reproduce this bug. Are people really that dumb? This bug is the easiest bug ever to reproduce.

For one of the explanations I wrote see:
https://bugs.launchpad.net/firefox/+bug/21202/comments/37

Tralalalala (tralalalala) wrote :

By the way: Why was LimCores tag deleted? He was completely right. I have to agree with him. Still having such broken copy and paste functionality after all those years while thousands of people keep on losing data IS an epic fail. This bugs importance has to be raised to the highest possible setting. Having an working copy and paste functionality is one the base components of an operating system.

No, Glipper is NOT a solution as it's full of bugs and only supports text.

Guilhem (logik-free) wrote :

Actually I think Patrick is completely right. This is an Epic fail. I'm now used to it (nearly 20 years of X practising), but newcomers will laugh and flee!

But IMHO I think the issue is with the way X selection works. Either gnome / put_your_wm_here drops Xsel and uses its own, dropping copy/paste support for any non-compliant application (not even imaginable I think), or Xorg developpers fix this and find a way to store the content (not only the source) on disk/ram as soon as Xselection is filled (both primary and secondary selection, please).

"Fix it in X, it gets fixed for everybody" (and drop glipper !)

PS : Not only you loose your Xsel when you close the program, but also when it hangs or freezes (which happens a lot with gnome apps! no flame here ;)

Mat Tomaszewski (mat.t.) on 2009-06-05
Changed in hundredpapercuts:
importance: Undecided → High
status: New → Confirmed
Sebastien Bacher (seb128) wrote :

Not really a papercut in my opinion, that's a design issue and not something that will be tweaking in a day

Vadim Peretokin (vperetokin) wrote :

As a workaround, http://parcellite.sourceforge.net/ seems to be solving this just fine somehow, while even giving the expanded functionality of being able to go in history of clipboard (so you can ctrl+c, ctrl+c, ctrl+v, ctrl+v) while being very lightweight (4.7mb for me atm with indicator-applet 6.1 with 1 app connected to it).

Vadim Peretokin (vperetokin) wrote :

^ pardon the bad sentence there.

Tralalalala (tralalalala) wrote :

Parcellite doesn't support images, sounds, some scene copied from a videofile, et cetera. It only supports text. Last time I tried Parcellite it was very unstable. We don't need half baked workarounds. We don't want to install an application for every desktop environment (Glipper or Parcellite for GNOME, Klipper for KDE).

Like Guilhem says:
"Fix it in X, it gets fixed for everybody" (and drop glipper !)

There shouldn't be workarounds for every single desktop environment out there. It needs to be fixed at the core.

The amount of discussion and divergent opinions expressed on this bug help show that this bug is well beyond the complexity of a paper cut.

Changed in hundredpapercuts:
status: Confirmed → Invalid
Guilhem (logik-free) wrote :

Could anyone explain me something : X does not remember the content of the selection, only the source. But why can't command line software like xsel or xclip output the content of the CLIPBOARD selection if it is binary ? see this :
a) select some text ("clipboard" for example), then CTRL-C :
xsel : clipboard
xsel -b : clipboard
b) right-click on an image in firefox for example the launchpad logo at the top of this page and CTRL-C :
xsel : [nothing]
xsel -b : [nothing]

what the heck ? what is xsel for if it only handles text? From the Lenny package description : "XSel is a command-line program for getting and setting the contents of the X selection.". It does not specify "text only".

Do firefox and gimp and openoffice and opera and [put your software here] use Xselection when copy/pasting images (or binary data) ?

Bernard Decock (decockbernard) wrote :

1. Ubuntu: Open Firefox. Copy the URL. Close Firefox. Open OOWriter : Can't paste url
   Windows : Open Firefox. Copy the URL. Close Firefox. Open OOWriter : Url pasted !

2. Open Firefox under Windows. Copy the URL. Close Firefox. Open OOWriter in a virtual machine(Sun Virtual Box) (UBUNTU9.4)
    One can paste the URL ! :-)

branvegeen (lekutakoa) wrote :

This not only happens to me with the text (now i use parcellite). It even happens by copying files between nautilus tabs!

In , sklp (sklp) wrote :

Created an attachment (id=384458)
Possible clipboard fix

In , sklp (sklp) wrote :

It seems to work for me, feel free to try, modify, and/or commit it.

In , sklp (sklp) wrote :

OK, have read a bit in the review info link, but I don't want to be an assignee or anything atm, just posted a patch that I thought could be useful.

@David Siegel, I don't think that the amount of discussion should be a factor on whether this is a papercut or not, nor do I believe that there are "divergent opinions" on this bug - everyone is pretty much saying the same thing - copy/paste in linux is laughably broken and has been for many years. The only divergence of opinion I'm seeing on this bug discussion is whether glipper/parcelite/etc are suitable workarounds. The common message seems to be that they are not, so this is still a papercut for nearly every user of linux, let alone Ubuntu.

Sure, perhaps this entails too much work for a papercut, but your stated reasons for changing its status are (I think) invalid.

Rickard: I think you may at least want to ask for caillon's review.

(From update of attachment 384458)
Can you please check this patch?

I once read an article, "why not to use klipper", I was using it. Now I just got used to not close the program. What about: http://svenfoo.geekheim.de/2005/06/18/why-klipper-is-bad/

Michael Nagel (nailor) wrote :

i felt we had established that "just do not close the program" is not an acceptable solution!

gimp enthusiasts hate klipper because it leeches everything it can get. if they were for a pragmatic solution they would not offer that much date but just an internal pointer. or klipper simply special-cases this scenario and everything would just work.

condemning klipper because there seems to be the golden bullet solution of integrating something into x does not take us anywhere.

one should elaborate a plan of how to get the x-solution because it is the right thing! but it will take its time to specify, implement and distribute. for the transition time we should use a program like klipper because there are just a few showstoppers to fix until it can be used as a decent quality workaround.

so i definitely suggest the following two-step approach:
1. use klipper to get things working in near future. pragmatically fix showstoppers as with gimp and problems with binary data. this could be done within weeks.
2. enhance the x server to make things "just work". this will take months to plan and coordinate and with implementation and release this could be more than a year. so an transitional solution as proposed in step 1 makes sense.

pyrates (pyrates18) wrote :
Download full text (6.0 KiB)

I'm glad I'm not the only this has effected. Why is this taking so long to fix? Could it be because traditional linux users don't want to lose the clipboard integration that they put into the terminal emulator? I'd bet so. This is unacceptable. Here's a write up of a frustrated linux user who tried to use the clipboard in linux from http://elliotth.blogspot.com/2008/08/desktop-linux-suckage-clipboard.html.

Desktop Linux suckage: the clipboard

X11's equivalent of the clipboard has been broken since I first used X11, back in 1993. 15 years later, things are still as bad as ever they were.

They say hard cases make bad law, and terminal emulators make very hard UI cases. Unfortunately, nerds being nerds, a terminal emulator tends to be the first application written for any Unix GUI. There are two main problems caused by starting with the terminal emulator and generalizing to the other 99% of applications. The more fundamental problem is that terminal emulators expect that most keystrokes can be passed through to the pseudo terminal, including the keystrokes that every other application on your system uses as keyboard equivalents for menu actions.

The X11-specific problem is that XTerm conditioned many long-term Unix users to use the selection instead of the clipboard. (If you're not an X11 user, you probably have no idea what I'm talking about here. Don't worry; we'll get to it.)

The big problem with the X11 clipboard is actually nothing to do with terminal emulators, except in so far as if they'd actually written some real apps instead of guessing what they might be and how they might behave, they probably wouldn't have crippled the clipboard in the way they did.

The easy one first, though. Mac OS uses a modifier key for menu actions (the "command" key) that didn't exist on traditional terminals, cleverly side-stepping the problem. PuTTY on Windows basically does without; a not unreasonable solution. GNOME Terminal uses control and shift (instead of just the "control" key). Terminator uses alt, which used to be popular on Unix, but fell out of favor in Linux times, thanks (I've always assumed) to the influx of Windows users.

As for the second problem, you may or may not know that Mac OS actually has multiple "pasteboards" (as usual, even their terminology is different). Mac OS hides them well enough that real people neither know nor care. Real people using Linux, even if they only use Firefox, get screwed by the old "selection" versus "clipboard" nonsense. Basically, in addition to the usual clipboard with its explicit "copy" and "paste" actions, there's a "selection". To set it you just select some text. To paste it, you press the middle button. (These days, the scroll wheel.) To paste it over existing text (such as in your web browser's location bar)... well, you can't do that. It's roughly that mistake that screws people over.

I see this catch people out at least once a week, and that's amongst X11 users savvy enough to simply shrug, mutter something along the lines of "bloody clipboard", and try again more carefully. As long Linux has no Steve Jobs to stand up and say "this is hurting us, so out it goes", I don't see this gettin...

Read more...

Tralalalala (tralalalala) wrote :

I already read it a few months ago, but it's a great article. That guy knows what he's talking about and I couldn't agree more.

Phylum (metus-m) wrote :

I know, this sucks. Normally on Windows platform source could be copied every though it's already closed. So when I'm on Linux, I have to be extra aware and extra careful by leaving the window of the copied source opened before pasting.

(From update of attachment 384458)
Karl, can you check this one please?

Remember "The clipboard contains a huge object, do you want to leave it?" message box when MS Office is closed?
Why not to do the same?!
If clipping text is not that big, then copy to "system buffer" w/o confirmation. If it's quite big (10/100/1000 Mb) - then ask.

The other workaround is to insert a special program (glipper or anything else) into a basic distribution.

This issue really affects me too, and I bump in it not only when source window is closed, but also when it's suspended (by "kill -SIGSTOP" or "Ctrl-Z")

pyrates (pyrates18) wrote :

Actually the way windows and OS X does it is if its text, its copied to the clipboard. If it's something larger like part of a graphic like photoshop does, they monitor the source. If the source is closed, that question pops up asking if the user wants to keep it in the clipboard. If they click yes, then it gets copied to the clipboard. If they click no, it simply is closed without anything further. If it's a file, its location is remembered only in the clipboard and that it is to be copied or cut no matter if the source window is open or not.

But fixing it in glipper is NOT the answer. That is a bandaid solution. It needs to be fixed in the Xorg layer where it is implemented in the first place, so that it is fixed for all DE's like gnome and kde.

(From update of attachment 384458)
Thank you, Rickard for submitting the patch.

It looks like gtk_clipboard_store() is a suitable function to use, but I don't
think we should be using it so often.

My reading of http://freedesktop.org/wiki/ClipboardManager is that it is
intended that the app should only ask the clipboard manager to save the
clipboard when the app is about to exit. I think the following clauses imply
this:

  "If a client needs to exit while owning the CLIPBOARD selection, it should
   request the clipboard manager to take over the ownership of the clipboard,
   using the SAVE_TARGETS mechanism."

   "the clipboard owner will quit upon receiving the SelectionNotify"

It looks like gtk_clipboard_store() passes ownership to the clipboard manager
immediately, and I don't think we want to do this every time
nsClipboard::SetData is called with new data for the CLIPBOARD.

Saving the clipboard involves converting the data (possibly of significant size) to a number of different target formats and transferring each of these (possibly across a network) to the manager.

The clipboard manager may even prompt to check whether the user really wants
to do this. (The spec says "possibly refusing to save large amounts of data,
or asking the user before doing so".)

Vish (vish) on 2009-08-23
tags: added: ayatana

I've merged some other bugs about the same problem into this one as duplicates, but I'm worried about it not copying the packages that are affected or upstream bugs. Do I need to manually move all those things to this bug, too?

This is something that needs to be implemented in each individual program, not system-wide?

Firefox : https://bugzilla.mozilla.org/show_bug.cgi?id=311340
Thunderbird : https://bugzilla.mozilla.org/show_bug.cgi?id=221183
Sunbird : https://bugzilla.mozilla.org/show_bug.cgi?id=412782
OpenOffice : http://www.openoffice.org/issues/show_bug.cgi?id=63092
Evolution : http://bugzilla.gnome.org/show_bug.cgi?id=258374
GIMP | GTK+ : http://bugzilla.gnome.org/show_bug.cgi?id=510230
Gnucash : http://bugzilla.gnome.org/show_bug.cgi?id=510205

description: updated
description: updated
Download full text (3.2 KiB)

After I reported a copy and paste related bug [Bug 417758] i was notified
that it was a duplicate of Bug 11334.

I read the report and thread for Bug 11334 and notified the person who
contacted me that my problem was NOT the same as one reported in 11334.

to reiterate and clarify:

Either:

 Bug 417758 is NOT a duplicate of Bug 11334.

Or:

 Bug 11334 does not describe the full scope of the problem.

Explanation:

The problem described in Bug 11334 is that if the user selects and copies
in one window, closes the source window, and the tries to paste into
another window the paste will fail.

The problem I reported in Bug 417758 is that if the user selects and copies
in one window and tries to paste into another window the paste fails even
if the source window remains open and the selection is intact. While the
problem is frequent it is also intermittent and reproducing it is a hit or
miss affair.

Please note that the thread for Bug 11334 attributes the problem to native
X-Window behavior, which could explain the problem described in 11334 but
DOES NOT EXPLAIN the problem described in Bug 417758.

These may be two different problems or Bug 11334 may be more extensive than
previously realized.

Please also note that I spent several frustrating hours last weekend on
correspondence regarding Ubuntu bugs including this issue and this will be
my last communication on the matter. I have found the correspondence i
received dismissive, condescending, and indicative of poor practice. (That
is, you are not reading the bug reports thoroughly.) I refuse to put any
more time into this.

IMHO the way this bug has been treated illustrates some of reasons Ubuntu
continues to have significant usability issues.

============
Eric Fluger

On Sat, 29 Aug 2009, Endolith wrote:

> Date: Sat, 29 Aug 2009 13:27:57 -0000
> From: Endolith <email address hidden>
> Reply-To: Bug 11334 <email address hidden>
> To: <email address hidden>
> Subject: [Bug 11334] Re: Copy-Paste doesn't work if the source is closed
> before the paste
>
> Previous discussions:
>
> http://elliotth.blogspot.com/2008/08/desktop-linux-suckage-clipboard.html
> http://linuxhaters.blogspot.com/2008/05/i-hate-copy-and-paste.html
> http://brainstorm.ubuntu.com/idea/3118/
> http://brainstorm.ubuntu.com/idea/16966/
>
> --
> Copy-Paste doesn't work if the source is closed before the paste
> https://bugs.launchpad.net/bugs/11334
> You received this bug notification because you are a direct subscriber
> of a duplicate bug.
>
> Status in One Hundred Paper Cuts: Invalid
> Status in Ubuntu: Confirmed
>
> Bug description:
>
> This bug is an Epic Fail, because it's 2009 and still we do not *fully* support trivial things like copy/paste.
>
> Fortunately this works well in KDE.
>
>
> This -could- be the underlying cause of bug #7986.
> This is a general issue that seems to be independant of any individual program.
> Pick any text field that supports copying, copy some text. Paste into any other
> text field. It works. Close the source window or program. Paste now does
> nothing. The example I just verified this with is gedit to gedit. Also occurs
> with openoffice to gedit.
>
> In some cases, like OpenOffice and ...

Read more...

The design of the clipboard isn't rocket science here. Implement it according to the way Windows does it. If an application wants to use the selection method of copy and pasting, then it takes over the ctrl+c ctrl+x ctrl+v shortcuts since it's most likely a terminal application. But most other applications are not and the selection method should therefore be disabled in the main clipboard implementation.

You may think you save time using the selection method, but it is NOT intuitive. And we wonder why at the beginning of every year someone announces that this year will be the year of the linux desktop and yet it fails to come true. This is why. Users expect stuff to be working properly and this is an example of something not working properly and the developers not caring enough because it works the way they want it to work and that's what matters to them. It doesn't matter to them that to most end users, it is broken and not working.

Michael Nagel (nailor) wrote :

ericf: if you do not close the source of the of the copy before pasting -- and nevertheless experience problems -- your problem is different from the bug discussed here and should be processed separately.
i mark it as no longer being a duplicate of this bug.

@pyrates
If it isn't rocket science for you, why don't you write a patch to fix it?
Most Ubuntu developers aren't paid for their work, they do it voluntarily.
And the number of Ubuntu devs isn't infinite.
Comments such as yours won't help fixing this bug.

xtknight (xt-knight) wrote :

Here's a workaround for firefox:

sudo apt-get install xclip

Edit /usr/lib/firefox-3.5.2/firefox.sh (or equivalent)
Put this line after #!/bin/sh :

python /home/$USER/clipwrap.py &

# Save this (for example) to /home/$USER/clipwrap.py

#Copy from the clipboard:
import os
import time
s = ''

while True:
    curs = os.popen('xclip -selection c -o').read()
    if len(curs)>0:
        s=curs
    else:
        wcl = os.popen('ps ax|grep firefox|grep -v grep|wc -l').read()
        if wcl[0]=='0':
            break
    time.sleep(.15)

os.popen('echo \"%s\" | xclip -selection c' % s)
#EOF

#Limitations are that it only works with firefox, and if anything else in ps ax matches firefox, it won't detect when firefox ends. Yeah, this could be better, but it's a proof of concept right now. This wrapper also only starts if something is on the clipboard to begin with. And you can adjust the sleep. Right now it wakes up every 150ms. That's bad for laptops or low-power machines. This needs to be fixed higher up on the "source chain". I'll try to make a better workaround too.

xtknight (xt-knight) wrote :

Oh umm another limitation is that it will only copy text, not html metadata in the clipboard. Same as ClipMan I think.

Guilhem (logik-free) wrote :

People on xdg mailing list were discussing about this back in '03. the thread is rather long... I always said it was a misconception in Xwin...

http://lists.freedesktop.org/archives/xdg/2003-August/000607.html

thank you for reclassifying bug # 417758.

IMHO it should not have taken hours of correspondence culminating in a
tantrum to get the matter attended to, but is appreciated none the less.

also IMHO...

a distribution targeting ordinary users would benefit from a consistent
stream of feedback from such users.

the current structure and atmosphere of the bug reporting system(s) are not
very inviting to ordinary users. this may be necessary as bugs reports
must be vetted and classified before bugs can be fixed.

if the experience of filing bug reports cannot be improved, perhaps it's
time to create a problem reporting system for ordinary, non-technical users
that is friendlier and less rigorous.

BTW:

if i have thoughts on the future of the clip board where would i send them
or post them?

============
Eric Fluger

On Sat, 29 Aug 2009, Michael Nagel wrote:

> Date: Sat, 29 Aug 2009 18:01:20 -0000
> From: Michael Nagel <email address hidden>
> Reply-To: Bug 11334 <email address hidden>
> To: <email address hidden>
> Subject: [Bug 11334] Re: Copy-Paste doesn't work if the source is closed
> before the paste
>
> ericf: if you do not close the source of the of the copy before pasting
> -- and nevertheless experience problems -- your problem is different from
> the bug discussed here and should be processed separately. i mark it as
> no longer being a duplicate of this bug.
>
> --
> Copy-Paste doesn't work if the source is closed before the paste
> https://bugs.launchpad.net/bugs/11334
> You received this bug notification because you are a direct subscriber
> of a duplicate bug.
>
> Status in One Hundred Paper Cuts: Invalid
> Status in Ubuntu: Confirmed
>
> Bug description:
> This bug is an Epic Fail, because it's 2009 and still we do not *fully* support trivial things like copy/paste.
>
> Fortunately this works well in KDE.
>
> This -could- be the underlying cause of bug #7986.
> This is a general issue that seems to be independant of any individual program.
> Pick any text field that supports copying, copy some text. Paste into any other
> text field. It works. Close the source window or program. Paste now does
> nothing. The example I just verified this with is gedit to gedit. Also occurs
> with openoffice to gedit.
>
> In some cases, like OpenOffice and Firefox, simply closing the source window
> won't cause the problem. It only happens if the entire program is closed down.
>
> When I copy (Ctrl + C, or right click and "Copy") text from somewhere and after that close the program where it is, the clipboard gets empty.
>
> This bug will happen in any application that doesn't comply with the clipboard specification from FreeDesktop.
> http://www.freedesktop.org/wiki/ClipboardManager
>
> Actual Status :
>
> Firefox, Thunderbird, Sunbird (Xulrunner) : https://bugzilla.mozilla.org/show_bug.cgi?id=311340
> OpenOffice : http://www.openoffice.org/issues/show_bug.cgi?id=63092
> Evolution : http://bugzilla.gnome.org/show_bug.cgi?id=258374
> GIMP | GTK+ : http://bugzilla.gnome.org/show_bug.cgi?id=510230
> Gnucash : http://bugzilla.gnome.org/show_bug.cgi?id=510205
>
> Pidgin : Fixed
> Inkscape : Fixed
> Gedit : Fixed
> Most Gnome apps, Fixed
>
>

ericf : Bug reports are used to fix bugs, therefore ordinary users can only help by providing informations to developers so they can fix these bugs. Discussions on bug reports make things more difficult for developers as it makes important informations hard to find. For that reason, launchpad should never be used to discuss in order to keep it doing a good work. http://brainstorm.ubuntu.com/ has been created to get user feedback. Thanks for your comprehension.

Tralalalala (tralalalala) wrote :
Download full text (3.1 KiB)

pyrates wrote on 2009-08-29:
"The design of the clipboard isn't...

...it is broken and not working."

I couldn't agree more!

Przemysław Kulczycki wrote on 2009-08-29:
"@pyrates
If it isn't rocket science for you, why don't you write a patch to fix it?"

Could people please STOP posting such comments? You people talk like everyone in the world knows how to program.

I also understand exactly how copy/paste works nowadays, how it should work and where it needs to be fixed. For me it also isn't rocket science. Does this mean I'm able to fix this problem? No, because I don't know how to program. Sure, I can do "Hello world" and some simple calculations, but that's all. When seeing the source code of other programs I don't understand anything. When do people start to realize not everyone knows how to program and how to fix bugs?

Przemysław Kulczycki wrote on 2009-08-29:
"Most Ubuntu developers aren't paid for their work, they do it voluntarily.
And the number of Ubuntu devs isn't infinite."

And that's the main problem of open source. Someone has an idea, starts to write some code and releases a bèta version. A lot doesn't work as it should work, but instead of first fixing those bugs, the developer starts integrating some new features. He has some cool ideas and he wants to implement them. True, what's more fun: fixing bug or adding cool new features? So the developer keeps on adding new features, but after years of development those bugs from the first build aren't even fixed.

Then the original developer doesn't want to go on developing his software, so he just stops. Some othet people pick up the code and start adding their cool new features, which also have some bugs. Those bugs also need to be fixed, but adding new features is more fun, so new features are added. It doesn't matter if people are complaining about those bugs, because the developers aren't paid, so they can do what they want: adding new features.

Ubuntu (actually Linux in general) has so many bugs that aren't fixed after all those years. No way you should see such thing in a commercial product like Windows or Mac OS, but in a free operating system like Ubuntu (Linux in general) this is possible. It's possible to not fix those bugs, even if they exist for more than ten years. What Ubuntu (or Linux in general) really needs are more paid developers, a bunch of paid professionals. Only then will there be "a year of the Linux desktop".

Przemysław Kulczycki wrote on 2009-08-29:
"Comments such as yours won't help fixing this bug."

The developers don't want to fix this bug, so it doesn't matter which comments are posted. All of them don't help fixing this bug. The only way to help fix this bug, is giving a professional programmer a whole lot of money if he fixes this bug.

P.S. After all those years this bug is still on the wishlist. Ridiculous! This isn't a wishlist, this is a bug of the highest priority as people are frustrated, because they constantly loose their work. Why do you think the market share of Linux grows so slowly? They try it, loose their work, because of this ridiculous 1980's-style copy/paste method and go back to Windows or buy a Mac.

This is a bug of th...

Read more...

Patrick,

while I also would like to see this big fixed I have to point out that your
rant is wrong on all counts.

Software in general has bugs that sometimes goes back years without getting
fixed. Proprietary software has the very same problem. To sell updates it
needs new features. So updates get rushed out with old bugs and plenty new
features. If you look around you'll easily find many examples of this.

Many open source programmers *are* paid - by IBM, Novell, Red Hat,
Canonical, Intel and many other corporations with an interest in Linux.

I also find this bug annoying - but it is not of the "highest priority" IMHO
- especially as a workaround has been available for years: glipper/klipper.

And lastly I can't agree that this is the reason why not more people use
desktop Linux. The primary reasons are that people can't pick a game in a
shop and be reasonably certain that their shiny new shrink wrap game works
right away. Similar for legacy apps in corporations. And most people still
don't even know that it exists. I put Ubuntu UNR on my sisters Netbook. Just
yesterrday a neighbour of hers easily browsed around on it with Firefox (by
now everybody knows Firefox :-) ). He later asked me if that was Vista
because he never saw this version of windows before. I told him it's Ubuntu
Linux - he said he never heard of it. And that's what most people (outside
of our geek circles) would say. There's no big TV ad campaigns for Linux -
nor is it prominently displayed in shops with retailers pushing it. And
regular folks out there don't read computer magazines, Wired or slashdot.
Linux grows slowly because it's expanding through a) geeks installing it on
their families/friends computers after those were overrun by windows malware
and a Mac was too expensive or b) by goverrnments trying to get more safety,
less costs or often just avoiding closed software from big american
copmanies they don't trust.

I would very much like to see this bug fixed, but installing k/glipper or
keeping the source app open while you copy/paste is not terribly difficult.
Some day a GSoC project or somebody from IBM/et al will fix it.

Some day its gonna be fixed? It's been 16 years. I can tell you what prevents me from using Linux is bugs exactly like this where the developer thinks its fine but 99% of users do not think it's fine. it's a bug. Fix it already. I don't care if its gonna take a lot of work, I'd like it fixed. Making excuses doesn't make up for the fact it's a bug, and a major one at that due to a design decision made in 1993.

I can tell you I won't be using linux until the developers behind it start taking it seriously by fixing major design problems just like this. Audio and video is another one and just being able to install a driver/module in linux is another one. What good is open source software if it doesn't work correctly?

Vish (vish) wrote :

The discussions on this bug report are becoming irrevelant and turning into personal attacks.
This bug report has the relevant information, just needs some attention from developers . There is no need to add a comment here which does not provide *useful* information to fix this bug.

To maintain a respectful atmosphere, please follow the code of conduct - http://www.ubuntu.com/community/conduct/ . Bug reports are handled by humans, the majority of whom are volunteers, so please bear this in mind.
Thanks!

affects: hundredpapercuts → null
John Vivirito (gnomefreak) wrote :

Added as MASTER bug for easy tracking. This bug should be against clipboard as i recall.

summary: - Copy-Paste doesn't work if the source is closed before the paste
+ MASTER Copy-Paste doesn't work if the source is closed before the paste

On 08/31/2009 04:56 AM, pyrates wrote:
> Some day its gonna be fixed? It's been 16 years. I can tell you what
> prevents me from using Linux is bugs exactly like this where the
> developer thinks its fine but 99% of users do not think it's fine. it's
> a bug. Fix it already. I don't care if its gonna take a lot of work,
> I'd like it fixed. Making excuses doesn't make up for the fact it's a
> bug, and a major one at that due to a design decision made in 1993.
>
> I can tell you I won't be using linux until the developers behind it
> start taking it seriously by fixing major design problems just like
> this. Audio and video is another one and just being able to install a
> driver/module in linux is another one. What good is open source
> software if it doesn't work correctly?
>
as said by someone above if you cant wait or you want it fixed
right away please provide a patch to fix it. If you can not
fix it yourself or choose not to than it has to wait for
someone to patch it.
You do know Ubuntu hasn't been around since 1993.
Since you saw this on other versions of Linux most likely is
due to upstream, please ask them to fix it if you can not

--
Sincerely Yours,
    John Vivirito

https://launchpad.net/~gnomefreak
https://wiki.ubuntu.com/JohnVivirito
Linux User# 414246

"How can i get lost, if i have no where to go"
    -- Metallica from Unforgiven III

Tralalalala (tralalalala) wrote :

Olaf wrote 6 hours ago:
"I also find this bug annoying - but it is not of the "highest priority" IMHO - especially as a workaround has been available for years: glipper/klipper."

I've said this many times: Glipper is not a solution and not even a good workaround. Glipper is unstable, 1 in 10 times when starting the system, Glipper doesn't start and Glipper only supports text. Copy an in image in Firefox (for example the Launchpad logo), close Firefox, start The GIMP, try to paste the image... impossible, even when using Glipper.

Olaf wrote 6 hours ago:
"I would very much like to see this bug fixed, but installing k/glipper or keeping the source app open while you copy/paste is not terribly difficult. Some day a GSoC project or somebody from IBM/et al will fix it."

As I said, Glipper isn't a solution nor a good workaround. True, keeping the source opened is the best workaround and I do this, but everytime I have to remember to not close the source before pasting. This is just so 1980's. It's completely ridiculous we have to keep the source opened in the year 2009!!! You can't expect new users to know they've to keep the source open to be able to paste. New users will everytime loose their work, because they don't understand what's going on under the hood. Ubuntu never says: "You've copied something, so you've got the keep the source open to be able to paste it somewhere else. Closing this window will loose the contents of the clipboard." How does a new user know he has to keep the source open. He always closed the source and then pasted the contents of the clipboard somewhere else when he was using Windows. This is the way a clipboard should work! Keeping the source open is completely ridiculous! We're living in the year 2009, not in the 1980's.

People are used to the way copy/paste works on Windows (which is the only good way to implement copy/paste) and when using Linux they have no clue what's going on. They keep on loosing their work and they haven't got a single clue they have to keep the source open. When I started using Linux, I've lost my work so many times and people are still losing their work, every day. Therfore this bug has to be marked as a bug of the HIGHEST PRIORITY, not as wishlist. Please, someone, change this to HIGHEST PRIORITY!

Guilhem (logik-free) wrote :

Everyone seems to say that osx behaves "correctly", but osx uses Xorg right ? Look at this page [http://www.x.org/wiki/XDarwin_Clipboard]
Couldn't it be an solution over there ?

Let me explain my idea of how it could work :
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...

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.

Download full text (4.4 KiB)

Howdy,

"I also find this bug annoying - but it is not of the "highest priority"
> IMHO - especially as a workaround has been available for years:
> glipper/klipper."
>
> I've said this many times: Glipper is not a solution and not even a good
> workaround. Glipper is unstable, 1 in 10 times when starting the system,
> Glipper doesn't start and Glipper only supports text. Copy an in image
> in Firefox (for example the Launchpad logo), close Firefox, start The
> GIMP, try to paste the image... impossible, even when using Glipper.
>

We're in total agreement about the solution and that glipper is not it. The
solution - of course - is to integrate proper clipboard management into the
DEs (Gnome, KDE, etc...).

I never had that instability though - glipper starts fine here - never
noticed that it didn't.

I admit that graphics are a problem. I rarely copy graphics that way (and if
>I do the source app stays opern for other reasons anyway) - so I didn't
suffer from that. But I get that it sucks if you do that a lot.

>
> Olaf wrote 6 hours ago:
> "I would very much like to see this bug fixed, but installing k/glipper or
> keeping the source app open while you copy/paste is not terribly difficult.
> Some day a GSoC project or somebody from IBM/et al will fix it."
>
> As I said, Glipper isn't a solution nor a good workaround. True, keeping
> the source opened is the best workaround and I do this, but everytime I
> have to remember to not close the source before pasting. This is just so
> 1980's. It's completely ridiculous we have to keep the source opened in
>

Again - we're not in disagreement about the goal. Only a very few very crazy
people would argue otherwise.
Yes - it would be way better if the clipboard would work as you and I and
practically everybody else and his sisters grandpa expects it to.

> the year 2009!!! You can't expect new users to know they've to keep the
> source open to be able to paste. New users will everytime loose their
> work, because they don't understand what's going on under the hood
>

Most users hardly ever use the clipboard that way. Heck - many users hardly
know how to use the clipboard.
It's already a challenge to train people not to use spaces as layout in word
processing apps.

> Ubuntu never says: "You've copied something, so you've got the keep the
> source open to be able to paste it somewhere else. Closing this window
> will loose the contents of the clipboard." How does a new user know he
> has to keep the source open. He always closed the source and then pasted
>

I agree that he doesn't. But there's a high chance s/he didn't close the
first app anyway.

> the contents of the clipboard somewhere else when he was using Windows.
> This is the way a clipboard should work! Keeping the source open is
> completely ridiculous! We're living in the year 2009, not in the 1980's.
>

You don't have to convince me - I'm pre-convinced. ;-)
We're in total 100% agreement about the solution.

>
> People are used to the way copy/paste works on Windows (which is the
> only good way to implement copy/paste) and when using Linux they have no
> clue what's going on. They keep on loosing their work and they haven't
> got...

Read more...

Olaf (tholap) wrote :

Apologies. The message above was not meant to go to the bug.

pyrates (pyrates18) wrote :

I say it should be fixed in the X.org layer. Otherwise you have DE's reinventing the wheel here when they shouldn't have to. Here is how it should be working:

1. Copy or cut something into the clipboard.
2. It copies directly into ram without needing the original app open after it's done.
3. If it is too large, put a message that it is unable to copy that large amount. It can test this by estimating how much memory it is going to take up.
4. When you close that app it stays there.
5. An app can set a flag that checks if its still in memory when exiting, then upon closing the app, the Xorg layer of the clipboard will warn the user that the app is leaving this in memory and asks the user if they want to clear it upon exiting the app. It can pause the exiting of the app to do this. This way we don't have to have a hard coded value. It is up to the app to correctly set this flag such as audio/video/image editing apps.
6. When the user has made up their mind of what they want to do, then the app finishes exiting.

The API needs the following features:

1. Estimation of how large the object is going to be in memory so that it doesn't take up all the users memory. A good percentage I think is 90% here.
2. A flag that is set that when the app has exited, X.org is to ask the user if they want to keep the clipboard contents in memory or delete them. When the user has answered this, then the app in question is allowed to continue exiting.
3. Confirmation that the object has been copied into the clipboard or if it hasn't, the reason why which goes to point 1.
4. When you cut an object, only delete the original if you paste the new object.
5. Object type that is copied into the clipboard. This is so that we can identify the object that is in clipboard and possibly identify which app would be appropriate to be able to use it in.

To expand on this object type, we can have 5 basic types:

1. Text
2. Raw Audio
3. Raw Video
4. Raw Images
5. A file

Just an idea here, what do the rest of you think?

pyrates (pyrates18) wrote :

Oh yeah and I almost forgot, remove the selection copy method. If an individual app wants to do it fine, but don't make it system wide by default. This way those who use terminal apps who want selection can still keep it. Then it doesn't interfere with any other app.

Putty on windows works this way, so it can be done.

Saivann Carignan (oxmosys) wrote :

pyrates : This is a bug report, ideas are counterproductive here. It is more appropriate to brainstorm on http://brainstorm.ubuntu.com which was created for that purpose. As repeated before, there is already a specification for clipboard which is good for old and new clipboard methods, the bug is simply that most software does not implement it correctly so re-inventing another specification is probably not likely to bring a solution to the problem.

Tralalalala (tralalalala) wrote :
Download full text (4.6 KiB)

Olaf wrote 21 hours ago:
"Though - come on - it shouldn't take too many losses to remember this behaviour."

How does a normal user know why the contents of his clipboard are lost? How does this user know he has to keep the source open? We know why this happens, but people on Launchpad aren't the average user.

My dad had forgotten his password for some website, so he clicked the "I forgot my password" link retrieve a new password. He opened Evolution, copied the password, closed Evolution and tried to paste his password in Firefox. Ofcourse this didn't work, so he though he didn't click on "Copy". He opened Evoltion for a second time, made sure he copied the new password and closed Evolution to paste the password in Firefox. After several tries he gave up. He really didn't know what was going on and he was almost going nuts.

He's an average user. How will he ever know he has to keep the source open? I use Google to get to know what's going on, but the average user doesn't do this. The average user just gives up and takes the telephone to call the person who installed Ubuntu and tells him he want Windows back, because Ubuntu doesn't work.

My dad doesn't search on Google. What should he enter in Googles search bar? He doesn't know what a clipboard is, he only knows: Right click and select "Copy" to copy and select "Paste" to paste. If this doesn't work, then he gives up. He doesn't know which words to enter to find a website which explains how copy/paste works in Linux and if he does find this website, he doesn't understand it, because he doesn't know English.

Olaf wrote 21 hours ago:
"I'm not saying it's good the way it is - but it's not the worst problem ever. And there's plenty of things with higher prority. On my personal list - remembering size and position of closed apps - so they open in the same position with the same size next time I open them - instead of "smart" placement that gnome devs prefered - would be a way higher priority in my book."

I don't know a single bug that should have a higher priority. The bug you're speaking of is, in my opinion, absolutely not a bug of high priority. The copy/paste bug causes many users to loose their work, every day. The size/position bug doesn't cause people to loose their work. Everything just works: The windows just open. The only thing you have to do, is drag and drop the window to the location to want it to be and make the window bigger or smaller. That only takes a second or maybe a few seconds, but that's all. In my opinion a low priority. The copy/paste bug causes people to loose their work. Every day people loose work, only because of this bug. A bug which causes so many people to loose their work just has to be a bug of the highest priority.

Olaf wrote 21 hours ago:
"Google is collecting ideas every year for GSoC projects. Write a proposal and submit it. Fair chance a student will be paid by google fixing this."

Ok, were can I do this? I can't find a page to submit ideas.

pyrates wrote 16 hours ago:
"Just an idea here, what do the rest of you think?"

Perfect.

pyrates wrote 16 hours ago:
"Oh yeah and I almost forgot, remove the selection copy method."

True, copy/paste with...

Read more...

pyrates (pyrates18) wrote :

Well said Patrick. So now it comes down to this:

Fix it. We as end users expect this to be working the way windows and OS X have implemented it. If it's not gonna be fixed to that specification, then I won't even think of using it. There's a reason why software companies can sell software and have the public buy it. Because if it is not usable to the end user, the end user isn't gonna use it. And that company will then go out of business. What incentive here does linux have?

As for just explaining it to the end user such as me why it doesn't work isn't a fix. If you have to explain how to do something, it's not designed correctly. If you wonder why OS X is the way it is, it is because they look at how you do something in it and they question it, how can we make this easier? This is the way Linux should be headed. Knowing there is a work around is not fixing it, it is avoiding it.

Vish (vish) wrote :

@pyrates :
For goodness sake! This is a bug report! Kindly do not spam this bug report with your rants !

Simply constantly stating "If it's not gonna be fixed to that specification, then I won't even think of using it."
Is not scarring anyone and i really dont understand why you think that statements is going to force a change!

As already stated several times , If you have such a huge passion for this and are capable of fixing it ,
- fix it or
- wait patiently for a volunteer to fix it or
- else *Pls do not use linux* .

There are several members subscribed to this report to know about the progress of the bug and not your empty threats or rants.
Thanks!

Micah Gersten (micahg) wrote :

@mac_v
To maintain a respectful atmosphere, please follow the code of conduct - http://www.ubuntu.com/community/conduct/ . Bug reporters and commenters are also humans, so please bear this in mind. :)

Created an attachment (id=407846)
an updated patch

Reworked patch, data are transfered to clipboard when app quits only.

Download full text (3.2 KiB)

(From update of attachment 407846)
What makes things awkward here is that Mozilla is using low level selection
functions and signals on its own GtkWidget mWidget to set data on the
clipboard, but gtk_clipboard_store() only works on higher level GtkClipboards
which have their own GtkWidget. There is no way to associate Mozilla's
selections on its own GtkWidget with GtkClipboards.

The patch here works around that (on quit) by changing the selection owner
from nsClipboard's mWidget to a GtkClipboard and adds code to convert the
nsITransferable to GtkClipboard format.

I'm not so enthusiastic though about having yet another place where
nsITransferables are converted to GtkSelectionData (and targets).

The conversion in nsClipboard::Store() of this patch does convert from
text/unicode _or_ images, but doesn't convert both text _and_ images (for
which support was added in bug 518249) and doesn't convert to other mime types
such as text/html (and maybe text/uri-list and text/plain, if they get used).

Also, the Clipboard Manager Specification says "Clients which support the
SAVE_TARGETS mechanism should announce this by listing SAVE_TARGETS as a
target for the CLIPBOARD", but with this patch that target only gets added to
the clipboard briefly on quit. I assume the intention is that the
SAVE_TARGETS target informs the clipboard manager that it doesn't need to
preemptively convert the clipboard selection whenever this app changes it.

I think the best solution is to make nsClipboard use GtkClipboards for setting
data. (It already uses GtkClipboard for getting data.)

nsClipboard::SetData() would use gtk_clipboard_set_with_data() and
gtk_clipboard_set_can_store() instead of gtk_selection_owner_set(),
gtk_selection_clear_targets(), and gtk_selection_add_target(s)().
(m*Owner and m*Transferable need to be set after gtk_clipboard_set_with_data()
as the GtkClipboardClearFunc will erase them.)

nsClipboard would no longer need mWidget. invisible_selection_get_cb() and
selection_clear_event_cb() would be replaced with the similar callbacks for
gtk_clipboard_set_with_data().

nsClipboard::SelectionGetEvent() would be similar, except the unused arguments
would be removed.

nsClipboard::SelectionClearEvent() would get a GtkClipboard instead of a
GdkEventSelection. That means the aEvent->selection is no longer available,
but the type of selection can be determined by comparing the GtkClipboard*
with gtk_clipboard_get(GDK_SELECTION_CLIPBOARD or GDK_SELECTION_PRIMARY).

nsClipboard::Store() would simply just call gtk_clipboard_store() and
nsClipboard::SelectionGetEvent() would be used for the conversion.

Little nits:

>+#define APP_QUIT "quit-application"

>+ os->AddObserver(this, "quit-application", PR_FALSE);

>+ if (strcmp(aTopic, APP_QUIT) == 0) {

I'd like each of these topics to be represented consistently.

As "quit-application" is only used twice, I'd suggest just using the string
literal each time.

>+ if (aTransferable == nsnull)

Mozilla style is "!aTransferable".
https://developer.mozilla.org/En/Mozilla_Coding_Style_Guide

>+ // Save global clipboard content to gtk
>+ nsresult Store (void);
>
> private:

Let's ...

Read more...

Ben Boeckel (mathstuf) wrote :

I haven't read all the comments here, but if this were my bug, I would "solve" it by just shipping a clipboard manager with the default install (Fedora does this I imagine and I know the KDE install comes with klipper by default). The behavior as-is is NOTABUG (using bugzilla notation here, not yelling) since this is how X works. If this is to be fixed for everywhere, it should go to X developers.

Just my two cents.

Okay, It would be better and more clear solution. I'll rewrite the patch...

Created an attachment (id=410768)
v3

A next version.

Store() has been removed because gtk_clipboard_set_can_store() is enough.

Data are set by gtk_clipboard_set_can_store(), GtkClipboardClearFunc is not used because we don't need that (do we?).

(From update of attachment 410768)
I like this much better, thank you.

(In reply to comment #37)
> Store() has been removed because gtk_clipboard_set_can_store() is enough.

That would be enough when Gecko is embedded in GTK apps using gtk_main
(because that calls _gtk_clipboard_store_all), but I don't understand how it
would work with a XUL app, which uses lower level event functions.

> GtkClipboardClearFunc is not used because we don't need that (do we?).

GtkClipboardClearFunc provides notification that something else owns the
selection. nsClipboard::SelectionClearEvent called EmptyClipboard which
released the nsITransferable and notified the owner with:

            mSelectionOwner->LosingOwnership(mSelectionTransferable);

This comment makes me suspect that this is important (though comments that say why are more helpful):

>- // XXX make sure to set up the selection_clear event

Nits:

>+ bool ImagesAdded = PR_FALSE;

I'd like avoid mixing types here. Either of the following would be OK:

  PRBool ImagesAdded = PR_FALSE;
  bool ImagesAdded = false;

>+ gint nTargetsNum;

Just |nTargets| or |numTargets|

>+ if(gtk_clipboard_set_with_data(gtkClipboard, gtkTargets, nTargetsNum,

Mozilla style is a space after "if".

>- nsCOMPtr<nsITransferable> trans = GetTransferable(whichClipboard);
>+ nsCOMPtr<nsITransferable> trans = GetTransferable(whichClipboard);

Unnecessary extra whitespace.

Created an attachment (id=411182)
v4

Should address the comments...

(From update of attachment 411182)
>+nsClipboard::Store(void)
>+{
>+ if (mSelectionTransferable) {
>+ GtkClipboard *clipboard = gtk_clipboard_get(GDK_SELECTION_PRIMARY);
>+ gtk_clipboard_store(clipboard);
>+ }
>+ if (mGlobalTransferable) {

http://freedesktop.org/wiki/ClipboardManager seems only intended for the
CLIPBOARD selection, not the PRIMARY. Also _gtk_clipboard_store_all() only
stores the CLIPBOARD, and gtk_clipboard_set_can_store() doesn't do anything when
clipboard->selection != GDK_SELECTION_CLIPBOARD so this first block won't do
anything, and so should be removed.

>+ PRBool ImagesAdded = PR_FALSE;

Variables in Mozilla usually start with lower case, so |imagesAdded|.
(Class names and function names start with upper case.)

>+ if (gtk_clipboard_set_with_data(gtkClipboard, gtkTargets, numTargets,
>+ clipboard_get_cb, clipboard_clear_cb, (gpointer)this))

The (gpointer) cast should be unnecessary because |this| is a |void*|.

>+ if (aWhichClipboard == kSelectionClipboard) {
>+ mSelectionOwner = aOwner;
>+ mSelectionTransferable = aTransferable;
>+ }
>+ else {
>+ mGlobalOwner = aOwner;
>+ mGlobalTransferable = aTransferable;
>+ }
>
>+ gtk_clipboard_set_can_store(gtkClipboard, gtkTargets, numTargets);

Can you move gtk_clipboard_set_can_store to the else block, please. There's
no difference in functionality because it won't do anything when
aWhichClipboard == kSelectionClipboard, but it makes the intentions clearer.

r=karlt with these changes.

Created an attachment (id=411407)
v4+updates

is sr requested here?

(From update of attachment 411407)
>+ // Store current clipboard content to GTK clipboard

"Ask the clipboard manager to store the current clipboard content" would be
more accurate.

No need to ask for further review (unless you want to make further changes). Thank you!

DieterVDW (dietervdw) wrote :

I'm a very technical guy, but I have work to do and not much time to do it in.
I don't want to lose time googling on how to get the copy-paste working.
Most users don't even start googling.
If you need to google to get it working, it doesn't work!

Please fix this. And I mean: I install Ubuntu and copy-paste works as expected. I don't care how.

As a sidenote, my mood currently agrees with everyone posting stuff like this:
... I cannot for one moment understand that something as primary as this didn't get fixed in the 5 year (five!! years!!!) this issue has been alive. It really causes me to slap somebody and resort to the "Linux is for techies out of touch with reality" tirade...
I really can't even begin to grasp why this isn't on top of the priority list. This makes me think very bad things about the decision makers at Canonical... Seriously frustrated...

John Vivirito (gnomefreak) wrote :

This has been reported to Mozilla a while ago but i do not have bug handy, When i get to my mozilla bug email folder i will see if it is there, but you can find it by searching Mozilla bugzilla. I will try to find it but may have better luck if someone else did as well since i can not be here a lot at this time

Saivann Carignan (oxmosys) wrote :

DieterVDW : While I understand your frustration (that we all share, I think), your comment here isn't helping much as bug reports should be used to work on technical aspects of bugs, not to discuss. Upstream bugs are listed in the bug description (including the mozilla/xulrunner one which currently have a very promising patch for review). I can't say if Canonical can or can't fix this problem, but apparently that this problem is out of reach for Canonical as it depends on all upstream projects that use clipboard so I doubt that this has anything to do with Canonical, but I might be wrong. Nevertheless, we should only comment here to provide relevant informations about the bug and/or potential fixes.

Micah Gersten (micahg) wrote :

The bug numbers for upstream are listed in the description of this bug. Not sure why there aren't bug tasks, but maybe it was so people aren't flooded for the stuff they don't want to follow. You can see the status of the upstream bugs on the right side of the bug in the section Remote Bug Watches.

Tralalalala (tralalalala) wrote :

Two weeks ago a friend of mine was using the GIMP to choose a nice color. When he found a color he liked, he copied the hexcode of the color, closed the GIMP and wanted to paste the color in KompoZer. As you can guess this was impossible. It happened a few times to him and he really didn't know what was going on.

A few days ago my father wanted to logon to a website, but he forgot his password. He clicked on the link called "Send me my password", he opened Evolution, copied the password, closed Evolution and wanted to paste the password in Firefox. You all know this is impossible. A few months ago I already told my dad this was impossible, but he forgot, so this time he again tried to use the copy/paste function the Windows way. Again he was confused and didn't know what was happening.

mac_v wrote on 2009-09-02:
"As already stated several times , If you have such a huge passion for this and are capable of fixing it ,
- fix it or
- wait patiently for a volunteer to fix it or
- else *Pls do not use linux* ."

Is it strange we have such a huge passion for this? The Linux way of using copy/paste just is a big, epic fail.
- Not everyone is a programmer;
- We've waiting for a fix since the first release of a graphical interface for Linux, but the progress is still ZERO!!! In all of those years there has been absolutely NO PROGRESS AT ALL and I doubt it ever be fixed.
- True, that's the best solution and that's why I'm going to sell all of my PC's and my laptop. I'm going to buy a few iMacs and MacBooks, because Linux just doesn't work. The market share of Linux is still an epic fail and do you know why? Because of these kind of stupid bugs which keep on bothering people, while there's absolutely no progress in fixing these bugs. The market share of Linux is incredebly low and that's exactly as it needs to be. An operating system which has such bugs since it's first release doesn't even deserve a good market share. Good to see your advice to not use Linux. I've already stopped to advice people to use Linux months ago. I give the advice to use Mac OS, as this works as expected.

DieterVDW wrote on 2009-11-13:
"I really can't even begin to grasp why this isn't on top of the priority list. This makes me think very bad things about the decision makers at Canonical... Seriously frustrated..."

Absolutely true.

The hyperbole this issue creates is fascinating.

First, I agree that the clipboard being so forgetful after an app closes is
an issue.
But some people here make it sound like it's comparable to critical security
issues, or major features missing.

It's not of the highest priority because there really are much higher
priorities. I really believe most people prefer speed and hardware support
and reducing reggressions as high priority issues.

And anybody switching to Mac or back to Windows and expecting 0 issues is up
for a rude awakening. All platforms have their silly issues. I get annoyed
every time my mousescroll doesn't scroll an underlying control - which
happens a lot on Windows - and never on Gnome, where the window doesn't even
have to have focus for the scroll to work.
And I recently did some tech support for a Mac user where not only where
some speed and file sharing issues - but it was easy - googling - to find
many other Mac users having the same problem. And don't get me started on
Apple clinging to the fantasy that 1 mouse button is enough.

But if having to paste first and close the first app later is too much
effort and this really is a fatal issue in anybodies opinion - then - yes -
pick a platform where the issues are a better fit for your preferences. None
of them is perfect. Pick whatever hurts you least.

Endolith (endolith) wrote :

Is there some good reason why Parcellite (or some other tool) isn't just included by default to work around this?

Jackflap (deriziotis) wrote :

Well, it looks like some nice developer has volunteered his time to the Mozilla suite to fix this bug (iirc), and progress is being made to fix this for Firefox.

https://bugzilla.mozilla.org/show_bug.cgi?id=311340

Also, please, less whining, and more contributing.

pyrates (pyrates18) wrote :

I wish this would get fixed in the Xorg layer instead. Fixing it on a per application basis takes more time then it should need to. And fixing it at the DE layer is a mere bandaid solution, meaning when it finally is fixed in the Xorg layer, the fix in the DE layer won't matter.

Tralalalala (tralalalala) wrote :

Olaf wrote 49 minutes ago:
"I really believe most people prefer speed and hardware support
and reducing reggressions as high priority issues."

The most important is to have an operating system you can trust, an operating system which is reliable, an operating system that doesn't forget something you told him only one second ago.

Olaf wrote 49 minutes ago:
"But if having to paste first and close the first app later is too much
effort and this really is a fatal issue in anybodies opinion - then - yes -
pick a platform where the issues are a better fit for your preferences."

It's not that keeping the application open is much effort, but you have to remember to keep an application open everytime you want to perfom a copy/paste. If you forget to keep the application open ALL WORK IS LOST. Besides that, how do people know they have to keep the source open? It isn't mentioned anywhere. According to http://marketshare.hitslink.com/operating-system-market-share.aspx?qprid=8 92.52% is running Windows and 5.27% is running Mac OS. That's 97.79% of all desktops in the world on which you don't have to remember to keep the source open. Because of this no one expects everything is lost after closing the source. How do you expect those switching from Windows or Mac OS to know they have to keep the source open? Almost everyone in the world will just close the source before pasting, because they expect it to work and they really have no clue what's going on if the option to paste is greyed out. They absolutely have no idea what's going on. How do you expect those people to know they have to keep the source open?

Keeping the source open is a strange way to copy/paste anyway. Just make it work as everyone expects it to work, The way it works on Windows and Mac OS is the abvious way for copy/paste to work.

Jackflap wrote 36 minutes ago:
"Well, it looks like some nice developer has volunteered his time to the Mozilla suite to fix this bug (iirc), and progress is being made to fix this for Firefox.

https://bugzilla.mozilla.org/show_bug.cgi?id=311340"

That's useless. It needs to be fixed in X, so it will work in every application and in every desktop environment. Now it'll be fixed in Firefox, but what happens when using the GIMP? Yes, copy/paste doesn't work. There are thousands of applications that can be installed, so it needs to be fixed in all of those applications. Do you think the developers of all of those applications will implement the clipboard specification from FreeDesktop? It's taking ages for a big application like Firefox to implement this copy/paste function, so how long do you think it will take for every application to implement this? Answer: it will never happen. There are too many applications and new applications keep on coming and almost none of these applications uses the clipboard specification from FreeDesktop.

Besides that, it will only work in Gnome. How about the other desktop environments and how about running KDE-applications in Gnome? As I said for about 30 times before: This is the wrong way to fix this bug. It needs to be fixed in X. After fixing X copy/paste will work in every applications in every desktop environment.

FMaz (fmaz008) wrote :

Olaf wrote 2 hours ago:
"It's not of the highest priority because there really are much higher priorities."

This problem have been reported more than 5 years ago. I think that this improvement should have been priorised over many other new features that are less important.

Yes it's not a major security problem, but it's so old that it start to cause frustration.

Endolith wrote 2 hours ago:
"Is there some good reason why Parcellite (or some other tool) isn't just included by default to work around this?"

It has been asked in the previous --and old-- comments. It seem to be cause that there software are not as versatile ( can't copy/paste some type of content )

srgb (work-serge) wrote :

Olaf wrote 2 hours ago:
"It's not of the highest priority because there really are much higher
priorities."

That's the point of discussion.
You think some new weird feature is a high prio.
I think (as most of distributors do) usability is the highest prio ever.

2009/11/20, FMaz <email address hidden>:
> Olaf wrote 2 hours ago:
> "It's not of the highest priority because there really are much higher
> priorities."
>
>
> This problem have been reported more than 5 years ago. I think that this
> improvement should have been priorised over many other new features that are
> less important.
>
> Yes it's not a major security problem, but it's so old that it start to
> cause frustration.
>
>
> Endolith wrote 2 hours ago:
> "Is there some good reason why Parcellite (or some other tool) isn't just
> included by default to work around this?"
>
> It has been asked in the previous --and old-- comments. It seem to be
> cause that there software are not as versatile ( can't copy/paste some
> type of content )
>
> --
> MASTER Copy-Paste doesn't work if the source is closed before the paste
> https://bugs.launchpad.net/bugs/11334
> You received this bug notification because you are a direct subscriber
> of the bug.
>

--
Serge Vinogradov
<email address hidden>
<email address hidden>
ICQ: 269813255

DanielRoesler (diafygi) wrote :

Patrick Roberts wrote:
> That's useless. It needs to be fixed in X, so it will
> work in every application and in every desktop
> environment.

Question: Is there a bug registered on the X bug tracker? If so, could we add it as an upstream bug report?

When I copy (Ctrl + C, or right click and "Copy") text from somewhere and after that close the program where it is, the clipboard gets empty. Windows and Mac OS X behave this way, so should Xorg.

A comparison:

   Ubuntu: Open Firefox. Copy the URL. Close Firefox. Open OOWriter : Can't paste url
   Windows : Open Firefox. Copy the URL. Close Firefox. Open OOWriter : Url pasted !

See here for one long discussion about it:

https://bugs.launchpad.net/ubuntu/+bug/11334

And it has links to many duplicate bugs of people wanting it fixed. Now I know this is mainly a design flaw and not a bug in code per say, but it's been 16 years now. It's time has come to be redesigned the way windows and mac os x do their clipboard.

Oh and this article is my favourite on it:

http://elliotth.blogspot.com/2008/08/desktop-linux-suckage-clipboard.html

PS I did do a search using clipboard as my search word and nothing like this has come up.

pyrates (pyrates18) wrote :

I dont think so. So I submitted a bug report:

https://bugs.freedesktop.org/show_bug.cgi?id=25220

Anyone want to add to it, feel free.

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 ?

Vish (vish) wrote :

Thank you for bringing this bug to our attention. However, a paper cut should be a small usability issue that affects many people and is quick and easy to fix. So this bug can't be addressed as part of this project.

For further information about papercuts criteria, please read https://wiki.ubuntu.com/PaperCut.

Don't worry though, this bug has been marked as "Invalid" only in the papercuts project.

Changed in hundredpapercuts:
status: New → Invalid
Endolith (endolith) wrote :

It can easily be fixed by installing a clipboard manager by default

Changed in hundredpapercuts:
status: Invalid → New
Vish (vish) wrote :

@Endolith:
Adding a new package to the default install is not a papercut task.
Kindly bring up the discussion for adding the package by default , in the desktop mailing list.

Changed in hundredpapercuts:
status: New → Invalid

If no further review is necessary, when will this patch land and on what branches? There are hordes of restless users in this downstream bug and it would be nice to give them some sort of bugfix ETA:
https://bugs.launchpad.net/ubuntu/+bug/11334

(In reply to comment #45)
> If no further review is necessary, when will this patch land

When someone checks it in on Martin Stránský's behalf. (Martin, could you post one final version with the comment-tweak that Karl suggested in comment 44? Then we can add the "checkin-needed" keyword to this bug, which will get your final patch noticed & checked in.)

> and on what
> branches?

Per the current settings of the "wanted1.9.2" and "blocking1.9.2" flags at the top of this bug, this isn't targeted for landing on any branches. Just on trunk (for Firefox 3.7+).

Created an attachment (id=414679)
what I landed

http://hg.mozilla.org/mozilla-central/rev/270a70535807

Martin Olsson (mnemo) wrote :

Good news guys!

This guy from Red Hat, called Martin Stránský, just fixed this bug in upstream Firefox! The mozilla devs merged the patch into the "mozilla1.9.3" branch (current hg master) which means that it will probably go out in Firefox 3.7

Firefox 3.7 won't be ready in time for Lucid though (see schedule here: https://wiki.mozilla.org/Firefox/Roadmap ) but there is always the possibility that someone (you?) will work with Alexander Sack and the rest of the Mozilla Ubuntu team to get this backported to the Firefox version in Lucid.

If someone is interested, the specific patch that fixed this bug looked like this:
http://hg.mozilla.org/mozilla-central/rev/270a70535807

We still need a more generic fix that handles all X.org apps of course.

Micah Gersten (micahg) wrote :

Tracking Upstream xorg request

Changed in null:
importance: High → Unknown
status: Invalid → Unknown
affects: null → xserver
affects: xserver → xorg-server
Changed in xorg-server:
status: Unknown → Confirmed
pyrates (pyrates18) wrote :

I'm not a programmer, so how was this fixed in firefox? What clipboard manager was it integrated with? Does that limit it to a certain DE then since this wasn't fixed in Xorg? Did they remove anything like the selection clipboard that uses the middle mouse button?

description: updated
Saivann Carignan (oxmosys) wrote :

pyrates : Xulrunner (Firefox) only fixed their clipboard code to comply with the specification, which is mentionned in the bug description. That only means that Firefox and other applications that rely on xulrunner (thunderbird, sunbird) will have clipboard working correctly, while other applications that still don't implement the specification correctly will continue to have problems. Primary clipboard (middle mouse button) won't stop to work in xulrunner.

I'm seeing this on the console a lot...

Gtk-CRITICAL **: gtk_clipboard_get_for_display: assertion `!display->closed' failed

sklp (sklp) wrote :

Sadly chromium/Google chrome also appear to have this bug...

http://code.google.com/p/chromium/issues/detail?id=32291

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.

LimCore (limcore) wrote :

This is crazy, this bug has 45 people that take time to go to LP and click affects-me-too,
it has a dozen of duplicates,
it is one of most reported bug I seen, and yet it is just Wishlist priority?!

Ubuntu fails to provide most basic functionality expected from a desktop since windows 3.11...

For 5 years now! Wow.

Micah Gersten (micahg) on 2010-02-09
description: updated
description: updated

That's so true...

I think a bug should be raised of priority when it start to flood the bug
tracker database with tons of duplicates & complains.

Actually, my nightmare are about me, learning C+ at a suffisent level to
submit a patch. IMO, that should also be considered as a good reason to
increase the bug priority.

2010/2/9 LimCore <email address hidden>

> This is crazy, this bug has 45 people that take time to go to LP and click
> affects-me-too,
> it has a dozen of duplicates,
> it is one of most reported bug I seen, and yet it is just Wishlist
> priority?!
>
> Ubuntu fails to provide most basic functionality expected from a desktop
> since windows 3.11...
>
> For 5 years now! Wow.
>
> --
> MASTER Copy-Paste doesn't work if the source is closed before the paste
> https://bugs.launchpad.net/bugs/11334
> You received this bug notification because you are a direct subscriber
> of a duplicate bug.
>

C de-Avillez (hggdh2) on 2010-02-09
description: updated
Vish (vish) on 2010-02-09
description: updated
LimCore (limcore) wrote :

WISHLIST - it turns out this is not a problem, even a bug marked just "Wishlist" will be worked on in case as this one (lots of duplicates and reporters etc).

According to guys at IRC ##ubuntu-bugs @ irc.freenet.org

Btw, and despite "epic fail" being removed from description, ubuntu devels also say that
"no one is disagreeing with you that it sucks" ;)

LimCore (limcore) wrote :

Imho this should be as one of "one hundred paper cuts".
If not, then please comment why not, thanks

Changed in hundredpapercuts:
status: Invalid → Confirmed
LimCore (limcore) wrote :

The addition or removal of a package is not a paper cut. "Replace F-Spot with Solang" is not a paper cut, neither is "Install simple-ccsm by default."
https://wiki.ubuntu.com/PaperCut ; Sorry my bad

Changed in hundredpapercuts:
status: Confirmed → Invalid
Endolith (endolith) wrote :

I'm not sure why this doesn't count as a papercut.

"trivially fixable usability bug that the average user would encounter in default installation of Ubuntu or Kubuntu Desktop Edition"

Isn't it trivially fixable by installing one of the workarounds by default?

On 09.02.2010 22:41, Endolith wrote:
> I'm not sure why this doesn't count as a papercut.
>
> "trivially fixable usability bug that the average user would encounter
> in default installation of Ubuntu or Kubuntu Desktop Edition"
>
> Isn't it trivially fixable by installing one of the workarounds by
> default?
>
A workaround is not a fix ;)
And to fix all the Applications, that do not handle the clipboard the
way the specification from FreeDesktop proposes, seems not to be trivial.

Maybe we need another project like "The Great Clipboard Fixing Galore
Project"..

Could someone explain why this isn't one of the first bugs to fix in hundred paper cuts where perfectly fits?
Could someone tell us when this bug will be fixed?

Many thanks

Jackflap (deriziotis) wrote :

Installing glipper or parcellite by default is not a fix, if we did that, then we wouldn't have solved the problem that the specification itself was designed to solve.

And the real reason this bug is not a papercut because it is not trivial. If it was trivial then someone would have fixed it already.

Every bug comes down to a cost-benefit balance. If the cost of fixing it is more than just living with it for every person, IT DOESN'T GET DONE.

A lot of you are asking stupid questions.. "why isnt it fixed, blah blah blah, whine whine". Well it's simple, in the same way that the cost of you learning how to program, studying the spec and implementing a fix isn't worth your time (or money), then for exactly the same reason no other dev has done it either.

Until someone has the necessary experience, time, or motivation to fix this, it will just sit waiting. The occasional reminder on the bug report is fine, but please, the best thing you can do is start learning to code and maybe a few years down the line you'll be able to write the patch yourself if it's so important to you.

Tralalalala (tralalalala) wrote :
Download full text (4.4 KiB)

LimCore wrote on 2010-02-09:
"This is crazy, this bug has 45 people that take time to go to LP and click affects-me-too,
it has a dozen of duplicates,
it is one of most reported bug I seen, and yet it is just Wishlist priority?!

Ubuntu fails to provide most basic functionality expected from a desktop since windows 3.11...

For 5 years now! Wow."

Yes, it really is an epic fail. :D Those developers really don't get it.

Endolith wrote on 2010-02-09:
"Isn't it trivially fixable by installing one of the workarounds by default?"

No, it isn't. How many times do I have to say it isn't? Those applications are NOT a fix. They're a workaround which somtimes works. Those applications also cause a lot of problems. I've tested all of them and there's none which really works. It just needs to be fixed in X, so there's a system wide clipboard which works for EVERY APPLICATION in EVERY DESKTOP ENVIRONMENT in EVERY DISTRIBUTION and for EVERY KIND OF CONTENT (like text, images, sound, a part of a video). Not like this will ever happen, because developers are as cocky and stubborn as can be, so don't a working clipboard in Linux in the upcoming 15 years.

You want an operating system which has a clipboard (one of the most basic features of an operating system)? Then just don't use Linux, because Linux doesn't have a working clipboard. We all know a working clipboard is something every operating system has to support. Every serious operating system in the world has one since it's first release, because a clipboard is so important. Everyone knows it's completely ridiculous to release an operating system without a working clipboard. I think developers of Linux don't cosider Linux a serious operating system, because after all those years it still doesn't work in Linux.

Look at this screenshot:
http://www.computerhovel.com/wp-content/uploads/2007/09/s10.jpg
That's Mac OS as it was released in 1984. Let me repeat that: NINETEEN EIGHTY FOUR!!! What do you see? Do you see the "Clipboard File"? Now it's 2010. Yes, it's TWO THOUSAND AND TEN!!! That's TWENTY SIX years later and Linux still doesn't have a clipboard which works.

Really, what an epic fail! Developers, what's your goal? You want Linux to be only used in CLI mode on servers or do you want Linux to also be used on desktops? If you want Linux to be not only used in CLI mode, then create something usefull, instead of this kind of amateuristic piece of... [insert some word or words you like to use when swearing].

Bartolomeo Nicolotti wrote on 2010-02-10:
"Could someone tell us when this bug will be fixed?"

What do you think of the answer: "Never" of "Certainly not before 2025"? In all those years Linux've never had a working clipboard, so don't think there'll a working clipboard in the near future.

Jackflap wrote on 2010-02-10:
"Well it's simple, in the same way that the cost of you learning how to program, studying the spec and implementing a fix isn't worth your time (or money), then for exactly the same reason no other dev has done it either.

Until someone has the necessary experience, time, or motivation to fix this, it will just sit waiting. The occasional reminder on the bug report is fine, but ...

Read more...

Jackflap (deriziotis) wrote :

Look it's open-source. It's an open-source development model. That's how it works.

Why do you have to rant and rave on a technical bugtracker about a development model that clearly doesnt satisfy your expectations?

Perhaps open-source just isn't for you.

pyrates (pyrates18) wrote :

Way to go @Tralalalala !

This is what happens when developers with no monetary incentives are put in charge of features in linux. And before someone comes in with IBM paying developers to work on linux, virtually none of it is in the desktop. It's all command line based because IBM makes their money doing service for servers, not desktops.

I've always posed the question with open source software but linux in general, if it wasn't free and you had to pay for a license to use it just like windows, in fact the same exact price per license, would you use it instead of windows? Or what if instead of windows, you could use Mac OS X for the same price per license, would you choose linux over it as a desktop?

If you can answer yes to any of this, I'd sure like to know why :)

And choosing it because it's open source is not a valid excuse. Don't involve politics or beliefs in your decision.

I do agree that this bug is an epic fail.
I do agree with the comment saying that we are users, not developpers.
(On this, I would also add that is really hard to join the developper
community, it's not user friendly at all.)

But I must disagree about the comment comparing Linux to Mac OS.
When people are not paid to do something, their are differences. The
difference is even bigger if the projet doesn't have the support of
the market ( we must do our own drivers for some material)

The work involved in linux is bigger because other OS doesn't
have to do this work... and their employe are motivated by their
pay.

That said, clipboard is an Epic failure and should be the priority #1 for
any future version, really.

--
---------------------------------------------
Francois Mazerolle, webmaster
---------------------------------------------
www.cybercity2034.com

pyrates (pyrates18) wrote :

I'd like to also add that putting in something like this isn't usually by a motivated developer. It's by a developer whose told by his boss or manager to implement this feature. This is why windows and mac os x has a proper clipboard. The developers have to implement it or they're fired. Despite what some people may think, Microsoft and Apple are motivated by features that their customers want. But they're also motivated to provide basic features that they know their customers will just expect them to implement, such as the clipboard.

FMaz (fmaz008) wrote :

@Jackflap:

No matter the development model, by it's nature, the project tend to a goal:
Be an operating system.

Having no real clipboard that really works is a failure to this goal.

2010/2/19 Jackflap <email address hidden>

> Look it's open-source. It's an open-source development model. That's how
> it works.
>
> Why do you have to rant and rave on a technical bugtracker about a
> development model that clearly doesnt satisfy your expectations?
>
> Perhaps open-source just isn't for you.
>
> --
> MASTER Copy-Paste doesn't work if the source is closed before the paste
> https://bugs.launchpad.net/bugs/11334
> You received this bug notification because you are a direct subscriber
> of a duplicate bug.
>

--
---------------------------------------------
Francois Mazerolle, webmaster
---------------------------------------------
www.cybercity2034.com

pyrates (pyrates18) wrote :

@jackflap

If you're motivated to use linux because the sole reason is that its open source, that's fine for you. It's not for the rest of the world.

And clearly you had no counter points to what was mentioned since all you can say is that open source isn't for him.

FMaz (fmaz008) wrote :

[off_topic]
I just notice that I've Nominated this bug for Lucid... Now that I see that I'm the only one who have done that, I'm asking myself if I really know that nominations are (as it's not explained, or hidden somewhere that I'm unable to find)

Do nominations are votes for the distribution we would like the bug to be fixed ?
[/off_topic]

Jackflap (deriziotis) wrote :

I didn't even read his post cuz he's just ranting.

This is not the place to rant. If ranting actually got any results, then I would be ranting myself.

The reason I use Ubuntu is because despite the (admittedly) really shitty bus like this one, I still prefer it to Windows and Mac OS X is too expensive.

Not only that, but the fact that it's open-source inherently means that you can never be locked-in, and that's the killer feature for me. It may be shit, and these bugs may be fail, but at least I have the option to use something else if I ever do get annoyed enough.

Don't get me wrong, these bugs are bad, but Ubuntu has a lot of great things going for it too. I'm really enjoying the lightweightedness and the super fast startup. I love VLC, and MythTV and the fact I've been able to customize the shit out of it.

I also firmly believe that one day this bug will actually be fixed..

On Fri, 2010-02-19 at 16:47 +0000, Jackflap wrote:
> Look it's open-source. It's an open-source development model. That's how
> it works.

Is it really every-man-for-himself in Ubuntu? Doesn't
Shuttleworth set priorities for each release? Isn't
there a paid Canonical development staff? Don't
they get together and put more priority on some
things than on others?

I ask in all seriousness... I'd like to know how,
if at all, this launchpad bug system interacts
with the way the core development team sets
priorities.

--
Dan Connolly, W3C http://www.w3.org/People/Connolly/
gpg D3C2 887B 0F92 6005 C541 0875 0F91 96DE 6E52 C29E

Saivann Carignan (oxmosys) wrote :

Dan Connolly : Developers regularly read bugs. When they can fix the bug, they assign the bug to themself and generally, it doesn't take a week before we get a update. Each Ubuntu release has blueprints, which are discussed in UDS with the ubuntu concil. Anyone can contribute and participate. However since ubuntu is a distribution, if this is not a mistake, the problem here doesn't seem to be the distribution but a software included in that distribution, namely xserver-xorg.

Of course Ubuntu could work together with xserver-xorg developer to find a solution, however, according to comments, this is not simply a bug fix, but a change in the clipboard specification. Therefore, I really doubt that ubuntu is the right place to ask this.

Users in this bug report complains that this bug exist since years and years and years, but if you look at freedesktop bug in xserver-xorg attached to this ubuntu bug report, it was reported 2009-11-21. Unless another older bug exist, apparently nobody complained at the right place since the beginning.

How intuitive that bug system is for casual users
In 5 years, no one has been able to report this bug to the right place. :(

Jackflap (deriziotis) wrote :

Dan,

Interesting question.

As we probably all know, Canonical have been pushing a usability drive, which is led by Mark Shuttleworth.

This has produced the FUSA applet (which was developed for 8.10), the notification area overhaul (included in 9.04), the theme updates (9.10) and we have the MeMenu and some other stuff due out with Lucid.

These initiatives seem to be directed by Mark Shuttleworth and he decides what is prioritized and focused on in every release. I would assume that he will eventually come round to addressing the clipboard at some point. Perhaps it's worth bringing it to his attention.

Most of the discussion seems to happen within the Ayatana project, so that may be a good place to start if you're interested in making some noise :)

Saivann Carignan (oxmosys) wrote :

Jackflap : As said previously, Canonical and Mark Shuttleworth are not in charge of xserver-xorg development. Ubuntu is a distribution. Canonical can contribute to bugfixes to upstream projects such as xserver-xorg, but drastic changes of concept needs to be done by the upstream projects themselves, by qualified developers.

If people start to pollute Ayatana discussions with this unrelated issue, there will be no benefit either for Ayatana and this bug report. Instead, invite every people who suffer from this bug to click the "Affect me too" button. That will give visibility to this bug to Canonical.

If this bug is not fixed yet, it's because it is not a easy bug, not because xserver-xorg or Canonical is not aware of this issue. However as long as you only refer to ubuntu bug report, xserver-xorg developers don't get any attention to this issue. And anyway, a bug report is not the right place to discuss, it only makes thing more difficult for developers as bug reports are polluted, therefore we should not be surprise that they stop using it, and work silently.

FUSA applet, notifications, simplescan, upstart are Canonical projects, not xserver-xorg.

FMaz : Linking a bug report can be done with two click, and launchpad has a good documentation. That only means that in 5 years, nobody took care to open and link a bug at xserver-xorg, users and developers.

FMaz (fmaz008) wrote :

"Linking a bug report can be done with two click, and launchpad
has a good documentation. "

Personnaly, I didn't even know that. Maybe it's easy when you know how to
do, but the interface is not intuitive for doing so.

Users will not read pages of documentation to report a bug. They already
must do an extra action over their regular work to report a bug, reading a
documentation should not be an obligation if the interface was good.

As for my question with the nominate for release, I really think I have done
something wrong with this, and I still don't know what exactly it is, and
how to remove it.

Lauchpad have a really bad user interace for the normal user (maybe
fonctionnal for debuggers, but NOT intuitive for users), but this point is
off the topic.

2010/2/19 Saïvann Carignan <email address hidden>

> Jackflap : As said previously, Canonical and Mark Shuttleworth are not
> in charge of xserver-xorg development. Ubuntu is a distribution.
> Canonical can contribute to bugfixes to upstream projects such as
> xserver-xorg, but drastic changes of concept needs to be done by the
> upstream projects themselves, by qualified developers.
>
> If people start to pollute Ayatana discussions with this unrelated
> issue, there will be no benefit either for Ayatana and this bug report.
> Instead, invite every people who suffer from this bug to click the
> "Affect me too" button. That will give visibility to this bug to
> Canonical.
>
> If this bug is not fixed yet, it's because it is not a easy bug, not
> because xserver-xorg or Canonical is not aware of this issue. However as
> long as you only refer to ubuntu bug report, xserver-xorg developers
> don't get any attention to this issue. And anyway, a bug report is not
> the right place to discuss, it only makes thing more difficult for
> developers as bug reports are polluted, therefore we should not be
> surprise that they stop using it, and work silently.
>
> FUSA applet, notifications, simplescan, upstart are Canonical projects,
> not xserver-xorg.
>
> FMaz : Linking a bug report can be done with two click, and launchpad
> has a good documentation. That only means that in 5 years, nobody took
> care to open and link a bug at xserver-xorg, users and developers.
>
> --
> MASTER Copy-Paste doesn't work if the source is closed before the paste
> https://bugs.launchpad.net/bugs/11334
> You received this bug notification because you are a direct subscriber
> of a duplicate bug.
>

--
---------------------------------------------
Francois Mazerolle, webmaster
---------------------------------------------
www.cybercity2034.com

pyrates (pyrates18) wrote :

If the xorg team refuses to implement the clipboard properly, and another group wants to fix it, fork it. You can do that. Or they can start from scratch like google did with Android because they saw that in order to fix stuff like implementing the clipbard properly, they had to replace xorg completely. If Ubuntu wants to follow that so that the clipboard works properly, I'm all for it.

As for Ubuntu calling it a linux distribution, they should rethink that strategy. Stop focusing on the fluff and start focusing on the essentials.

@Flapjack

So you've confirmed that you use linux because it's open source. Thank you for your bias.

Jackflap (deriziotis) wrote :

Saïvann : It's not only up to xserver-xorg to fix this. There is an independent Freedesktop specification outlining how the clipboard works. It says clearly that all applications, when quitting should export the clipboard contents to the global clipboard.

xserver-xorg actually adheres to the specification properly. It's actually everything else which are behaving incorrectly (a couple of them actually already work properly). So I wouldn't say that it's up to xserver-xorg to break the spec and fix this.

If anything, maybe the spec should be improved, then xserver-xorg will be obliged to fix the behaviour. However I never felt technically comfortable enough to start a discussion on the Freedesktop mailing list since I don't feel I understand the underlying issues well enough.

That being said, if the Canonical usability decided to focus on the clipboard for a release, the absolute bare-minimum that they would do would be to correct the behaviour of all applications installed by default. This would be a massive improvement already. They would probably also work with the Freedesktop spec in order to improve it (as they did with the notification area and are doing with the application indicators). Who knows, with any luck they could improve the clipboard beyond how it is implemented in Windows/Mac.

One thing that stands out to me, is that there are no launchpad bugs for each independent application linked to this one. Someone should really go and find/submit the related bugs and link them to this one.

Download full text (4.7 KiB)

You are correct in your statement, if you just read the bug description,
there is almost no mention about xserver-xorg. The idea that the
specification should change (which means modifying xserver-xorg
behavior) only appears in last comments. Some users speaks like if this
has always been THE solution.

However, at the very first beginning, there was already a specification
so any apps that is closed can register it's clipboard content, so the
clipboard don't get lost once this application is closed.

However, most developers and users don't like this specification,
because it's not how clipboard works on windows and Mac for instance.
Added to the difficulty level to fix this, the reticence of upstream
developers is one of the first reason why this bug still exist and is
still annoying.

Therefore even if everybody claims to have THE solution, it's more
basically a war between two opinions :

1. All applications should comply with clipboard specification.
2. Xserver-xorg should improve and clean up his clipboard (and drop.. or
dratically change his "Selection" methods, that many developers love and
used since the beginning of xserver-xorg so it won't interfere with the
basic features of clipboard.)

Each of these idea is insane, as it requires a lot of work, because
xserver-xorg is not a brand new project, the quantity of people and
projects that relies on it is montruous.

Of course, as you said, if one day xserver-xorg decide to attack idea
#2, they will work with freedesktop to create a new specification.

However your last statement is wrong, there is a bug report for many
applications concerning this, you can all find a list of fixed and
unfixed bug reports in the launchpad bug description. I actually was the
one who managed to merge a ton of bugs all about this issue 1 year ago,
and after reading them all, I found reference to the specification in
one of them, and therefore I made sure that every important projects
(such as evolution, firefox, etc.) was aware of this, by opening a bug
report in their bug tracking system, and adding a reference to this in
the launchpad bug report description.

And of course anybody can report this bug to any other upstream project
that is not already listed in the description. That means searching for
the bug tracking system of the said application on Google, subscribe
there, search if the bug is not already reported, and if not, report a
new bug, and finally, take the address of the bug and add it to the
launchpad bug description.

Unfortunately, once I made that for all the most important projects, the
bug almost got only users complaining, but nobody wiling to take a few
minutes to verify if they could improve the bug report by adding their
own applications if they also have the bug. The description almost
didn't change for more than one year.

However if you look at the bug description, you'll notice that it's
fixed in most GNOME applications, and all future xulrunner applications
(firefox, thunderbird, sunbird, etc.).

I'm not expert enough to have my opinion on what should be done. Idea #1
and #2 seems to both have many good and bad sides.

Saïvann

On 2010-02-2...

Read more...

description: updated
Tralalalala (tralalalala) wrote :
Download full text (9.5 KiB)

Saïvann Carignan wrote 19 hours ago:
"Developers regularly read bugs. When they can fix the bug, they assign the bug to themself and generally, it doesn't take a week before we get a update."

That's the best joke I've ever heard. None of the bugs I've commented on has ever been fixed. Bugs which are several years old still got the status "New". This Bug reporting system is just a fail. You're only talking to other users who experience the samen bugs, but you never see a developer.

Saïvann Carignan wrote 19 hours ago:
"Users in this bug report complains that this bug exist since years and years and years, but if you look at freedesktop bug in xserver-xorg attached to this ubuntu bug report, it was reported 2009-11-21. Unless another older bug exist, apparently nobody complained at the right place since the beginning."

They know about the crappy clipboard for years:
http://www.x.org/wiki/XDC2007Notes#BartMassey.3ACutandPaste
That's from the X Developer's Conference of 2007.

Besides that:
How can you expect the average user to know which developer develops each part of Ubuntu and where to find the particularly bug tracking system of that developer and to create an account at all of those bug tracking systems?

For example:
Someone encounters the bug of this bug report, he encounters a bug in Rhythmbox, he encounters a bug in OpenOffice.org and he encounters a bug in The GIMP. This means the user has to know the developers of X are the one to blame for the non-functional clipboard and he has to search for the bug tracking system of X. Then he has to create an account, he has to search if the bug is already reported and if the bug isn't already reported he has to report the bug for himself and has to answer difficult questions, like "Product". Look at the bug report at this location:
http://bugs.freedesktop.org/show_bug.cgi?id=25220

Look at the drop down menu behind "Product". It goes from "accountsservice" to "Xtests", there are so many products in this list, I'm not even going to count all of them and all of those products've got weird names, like "xesam", "scim", "roadster", "libasyncns" or "exempi". How in the name of [actually I really don't care in the name of who] will the average user ever be able to find the product which belongs to the behavior of the clipboard? That's just impossible. Only a very small amount of users will be able to report such kind of bugs.

The user's also got a problem with Rhythmbox, so there we go again: He has to know who's the developer of this application, search for the bug tracking system of this developer, create an account, serach if the bug already exists and report the bug. Then he also has to do this for the bug in OperOffice.org and the bug in The GIMP. You can't expect this from the average user. It's way too much hassle, it costs way too much time and it's way too difficult for the average user. It's way too technical. The average user doesn't understand this.

The average user installs Ubuntu and for the user Ubuntu is the operating system, so if he encounters any bugs, Ubuntus Launchpad is the place to report these bugs. The user doesn't know (and really doesn't want to know) who developed wh...

Read more...

pyrates (pyrates18) wrote :

So linux does it differently compared to the method that windows and OS X does? Why not do it the same? Why don't we change the freedesktop.org to match how windows and OS X does?

I agree with developers who refuse to implement it because it's not the same on windows and OS X, that it's stupid. Why should a developer need to change their applications behavior for linux when the same behavior works on windows and OS X?

This should be fixed in xorg. That way it's automatically fixed in all linux gui based applications. The only applications that should be checking the clipboard contents when they exit are ones that copy large chunks of data like chunks of audio or video for example.

What's stopping this? Stubborn developers who think that the terminal application should come first that want their selection based copy and paste to still work. It's a small number of developers too that is causing pain for everyone else.

But if xorg is forked and the clipboard is implemented just like in windows and OS X, I wonder how many distributions will drop xorg and put in the replacement for it. That will show you truly if a linux desktop distribution is for ordinary users or the traditional linux developer from 1993.

I hope that it's a group of developers from Ubuntu, because that would truly show that Ubuntu wants to be the linux desktop distribution of choice. I know they can do it.

Saivann Carignan (oxmosys) wrote :

At the mean time, as continously repeated, using a bug report as a forum will only prevent developers from working with it.

If you want Canonical to notice the priority : Click affects me too.
If you want xserver-xorg or other projects to notice the priority : subscribe yourself to upstream bug report.

There are two solution :
1. Adopt the current standard, which is not bad at all, and implemented by many projects.
2. Drop features that many users use in xserver-xorg to be "like" other OS and change the specification to be more simple.

Both have good and bad sides.

If you really want this to be fixed, you can get involved. However insulting others if they don't involve in the delay you expect, or thinking that a solution that please you is the right one for every users is counterproductive, not collaborative, not respectful and does not considerate others.

Therefore, it is completely against Ubuntu code of conduct.

http://www.ubuntu.com/community/conduct

description: updated
Sandro Mani (sandromani) wrote :

Geees will people stop complaining for something they got for FREE? It is like if you got a present and start insulting the person which gave it to you because it does not work the way you want. It is certainly okay to point out things that have some design flaws, but please just try to keep in mind that
1) If there were such a trivial fix, it would already have been fixed
2) You cannot simply swap out something buried so deeply into the window manager without risking considerable breakage
3) The person(s) who originally implemented the clipboard may very well not be working on Xorg anymore, hence someone would have to read through the whole unfamiliar code and understand it, just like we
4) Developers are not our slaves, and calling them stubborn and whatever surely won't motivate them to give up more of their free time for people insulting them

If we are so determined to see this issue fixed, why not just create a wiki page somewhere and work together to
- Identify what is wrong with the current specification
- Find out how it works on mac and windows, and discuss what the correct specification should look like
- Find out how the current clipboard mechanism is integrated with the other components of the window manager and identify the critical parts which could cause breakage if altered
- Work on a fix

It is obvious that this is a lot of work, but so would it be for any developer willing to fix it, and the chances of success are considerably higher if the 52 people here would spend time researching instead of writing long, heated comments.

Guilhem (logik-free) wrote :

This bug is harder to fix than I thought : I thought it was the X server's responsability to claim the xclipboard when an client exits (thus a bug in Xorg), but the freedesktop xclipboard specification are very clear :

" If a client needs to exit while owning the CLIPBOARD selection, it should request the clipboard manager to take over the ownership of the clipboard, using the SAVE_TARGETS mechanism. If there is no clipboard manager, or if the SAVE_TARGETS conversion fails, the application should simply exit. " [http://www.freedesktop.org/wiki/ClipboardManager]

#1 If we follow the specs, every client that does not follow it has to be updated ; might take much longer time than changing Xserver's role in clipboard managment. #2 On the other hand, adapting the specs and Xserver behaviour might solve it for every client at the great risk of breaking lots of living apps out there.

I still think we should go for #2, extending it to allow Xserver to grab Xselection as soon as CTRL-C is called ; this way it could prevent a clipboard loss in case the client freezes.

What should we do ?

Saivann Carignan (oxmosys) wrote :

Indeed. From a user point of view, it's hard to know what changes will affect a lot of projects and people, that's the developer task. Firstly, this bug has to gain visibility to Canonical and xserver-xorg, so appropriate developers can take a look at it. Since this bug has 52 people affected, this makes it visible in page two of hot bugs, which means that it has probably been already considered by Canonical.

Since a major change in clipboard was already considered by xserver-xorg developers in the past, it's most likely that it will eventually done. But since it far more than a normal bugfix, I don't see anything else we can do without expertise in xserver-xorg and collaboration with the upstream project. If anyone know a developer that knows very well xserver-xorg that is wiling to put enough time on this and work with the upstream project, then things might accelerate. The bug report itself is complete and does not require any other information.

The popularity of the bug, the amount of work necessary and the consequences of changing the specification is what will affect the correction of this bug for Canonical and xserver-xorg in my opinion.

Dan Connolly (connolly) wrote :

On Sat, 2010-02-20 at 19:13 +0000, Tralalalala wrote:
[...much ranting elided...]
> Users are losing their work time after time. They write a large e-mail
> in OpenOffice.org (yes, some people do such things), then copy
> everything, close OpenOffice.org and start Evolution to send the
> contents of the clipboard to someone. This works in every operating
> system (except Linux) and users are used to this behavior. It's
> completely obvious this works, always and everywhere. It's completely
> obvious to expect this behavior in Linux and it's completely ridiculous
> this doesn't work in Linux. For a user it's completely obvious the
> content isn't lost, so a user just closes OpenOffice.org and is really
> surprised when he wants to paste the content of the clipboard in
> Evolution and the clipboard is empty. A user really doesn't know what's
> going on and he's lost maybe an hour of work!!!

Indeed, this is what concerns me. When I was doing product development,
a bug that caused loss of user data was SEV 1 and took priority over
just about everything else.

I'm having a hard time reconciling this with "Importance: wishlist"
in launchpad.

While I acknowledge the challenge of getting the problem fixed
in a large variety of applications, I think a lot of the
heated discussion here would be reduced if launchpad more
clearly acknowledged the severity of the bug.

The "affects me too" mechanism is relevant, of course; evidently
53 people have found/used it. But when people are affected by
this bug, they're much more likely to throw their computer out
the window than learn about launchpad and find the
"affects me too" button.

On Fri, 2010-02-19 at 20:24 +0000, Saïvann Carignan wrote:
> Dan Connolly : Developers regularly read bugs. When they can fix the
> bug, they assign the bug to themself and generally, it doesn't take a
> week before we get a update. Each Ubuntu release has blueprints, which
> are discussed in UDS with the ubuntu concil.

What's UDS? Whats the ubuntu council?

Ah..

"At the beginning of a new development cycle, Ubuntu developers from
around the world gather to help shape and scope the next release of
Ubuntu. The summit is open to the public, but is not a traditional
conference, exhibition or other audience-oriented event. Rather, it is
an opportunity for Ubuntu developers - who usually collaborate online -
to work together in person on specific tasks."
 -- http://www.ubuntu.com/news/spotlight/uds

"The social structures and community processes of Ubuntu are supervised
by the Ubuntu Community Council. It is the Community Council that
approves the creation of a new Team or Project, and appointment of team
leaders. ... You can submit an item or proposal for discussion by the
Community Council using the wiki page CommunityCouncilAgenda. "
http://www.ubuntu.com/community/processes/council

Thanks. That's the sort of answer I was looking for when I asked how
development priorities get set.

--
Dan Connolly, W3C http://www.w3.org/People/Connolly/
gpg D3C2 887B 0F92 6005 C541 0875 0F91 96DE 6E52 C29E

Saivann Carignan (oxmosys) wrote :
Download full text (4.4 KiB)

Hi Dan Connolly

I'm answering you directly if you don't mind to don't spam other users.

Actually I doubt that the priority has been set by a developer yet,
therefore the current priority is probably only there to make sure that
they notice the bug. This bug is older than the "Affect me too" feature,
therefore bug triagers were more likely to use Importance field to bring
some bugs to the eyes of the developers.

This status could even have been set by me, when I was a member of the
bug control team during the last year. But it's more likely to be a
temporary status, however I agree that it's frustrating at the moment.

I understand your concerns and they're all valid for sure. I don't know
what else to say because I don't have any more information about this, I
already did what I could do : making a well written bug report based on
all information I found about this issue in all duplicate bugs, I
reported the issue to most popular upstream project and merged all
duplicates together.

Therefore for the next part, I think that this would need to be
discussed with ubuntu X developers or X developers themselves. At a
first glance, I would say that the Ubuntu X team is probably the good
place to speak about this issue concerning Canonical, if it was your
intention.

https://wiki.ubuntu.com/X

Thanks for your interest in improving the situation of this bug.

Best regards,

Saïvann

On 2010-02-22 10:15, Dan Connolly wrote:
> On Sat, 2010-02-20 at 19:13 +0000, Tralalalala wrote:
> [...much ranting elided...]
>> Users are losing their work time after time. They write a large e-mail
>> in OpenOffice.org (yes, some people do such things), then copy
>> everything, close OpenOffice.org and start Evolution to send the
>> contents of the clipboard to someone. This works in every operating
>> system (except Linux) and users are used to this behavior. It's
>> completely obvious this works, always and everywhere. It's completely
>> obvious to expect this behavior in Linux and it's completely ridiculous
>> this doesn't work in Linux. For a user it's completely obvious the
>> content isn't lost, so a user just closes OpenOffice.org and is really
>> surprised when he wants to paste the content of the clipboard in
>> Evolution and the clipboard is empty. A user really doesn't know what's
>> going on and he's lost maybe an hour of work!!!
>
> Indeed, this is what concerns me. When I was doing product development,
> a bug that caused loss of user data was SEV 1 and took priority over
> just about everything else.
>
> I'm having a hard time reconciling this with "Importance: wishlist"
> in launchpad.
>
> While I acknowledge the challenge of getting the problem fixed
> in a large variety of applications, I think a lot of the
> heated discussion here would be reduced if launchpad more
> clearly acknowledged the severity of the bug.
>
> The "affects me too" mechanism is relevant, of course; evidently
> 53 people have found/used it. But when people are affected by
> this bug, they're much more likely to throw their computer out
> the window than learn about launchpad and find the
> "affects me too" button.
>
> On Fri, 2010-02-19 at 20:24 +0000, Saïvann ...

Read more...

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.

LimCore (limcore) wrote :

Just install Percellite by default (MIR) and we are done! No need for too much talking, lets do it ;)

pyrates (pyrates18) wrote :

@LimCore

Have you been paying attention? We don't want a bandaid solution or a work around. We want it fixed at the source. And that includes getting rid of the stupid selection based copy and paste that only appeals to those who want the terminal app to come first when it shouldn't even be required in the first place. Apple did it, so can linux.

toobuntu (toobuntu) wrote :

Would it be out of place to suggest that an entry be added to the release notes that this is a known issue and give the workarounds of: (1) leaving the source window or program open until after the paste is complete or (2) installing parcellite (any), glipper (Ubuntu), or klipper (Kubuntu)? I do not know who is involved with the release notes; would somebody please bring this to the appropriate person's (or team's) attention for comment?

On Tue, Feb 23, 2010 at 10:15:46AM -0800, <email address hidden> wrote:
> Tralalalala <email address hidden> changed:
>
> What |Removed |Added
> ----------------------------------------------------------------------------
> CC| |<email address hidden>
> Severity|normal |critical
> Priority|medium |highest
>
>
>
>
> --- Comment #5 from Tralalalala <email address hidden> 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.

@toobuntu:
That would be a great idea. Not yet an acceptable solution, but at least
give the feeling that the *problem* is officially recognized by the dev
team, and not just a "wish".

Tralalalala (tralalalala) wrote :

Sandro Mani wrote on 2010-02-21:
"The person(s) who originally implemented the clipboard may very well not be working on Xorg anymore, hence someone would have to read through the whole unfamiliar code and understand it, just like we"

Then there's something fundamentally wrong at Xorg. It doesn't matter who wrote the code. If Xorg releases some software, they're responsible for maintaining the code and they're the ones who need to ensure everything is properly documented, so it's possible to make some changes to the existing code.

Sandro Mani wrote on 2010-02-21:
"the chances of success are considerably higher if the 52 people here would spend time researching instead of writing long, heated comments."

Researching? That's work for developers, not for users. I've said it so many times, but how can Linux ever get a market share of more than 1% if they expect the users do everything themselves?
Step 1: User encounters a bug;
Step 2: User tells developers he found a bug and gives some information like when does he encounter this bug and what did he expect to happen;
Step 3: Developer researches how to fix this bug;
Step 4: Developer fixes bug;
Step 5: Developer releases an update.

Unfortuantely this doesn't work with open source software, because the developer says: "I don't give a fuck about that bugs. Fix it yourself."

Users don't want to do research, they don't want to create Wiki-pages, they don't want to learn how to program. They just want to tell the developer about the bug he encountered and that's all. They encounter this bug, because of the errors of the developer, so he's the one who needs to fix the bugs he created himself.

Why does the term "open source developer" mean "someone who who does what he wants to do, but doesn't listen to the comments of the users"? If you only implement features you like yourself and only fix bugs you care about, then don't release your software to the public, but keep it just for your own use. If you also want other people to use your software, then listen to them and implement the features they want and fix the bugs they want to be fixed. If you don't want to do this, then just dont release your software to the public, because users expect software to work. They just want to use the software, they don't want to help develop the software.

LimCore wrote 4 hours ago:
"Just install Percellite by default (MIR) and we are done! No need for too much talking, lets do it ;)"

It has been said so many times: this is not a solution. These kind of applications are a bandaid solution to get some half baked clipboard implementation which crashes sometimes and doesn't even support all kinds of file types. Besides that, installing such application by default will cause the developers to think: "They've got their clipboard implementation, so there's no need to deliver a real fix." We need the clipboard to be implemented where it needs to be implemented.

FMaz (fmaz008) wrote :

Ok folks, their is 3 things that can resume this 200+ messages thread:
1) Many people want a bug fix, not a workarround;
2) The bug is too complex to be fixed by users, and will need a -- if not many-- really good developper to be fixed;
3) It seems like it's a X / xorg bug, not a Ubuntu or Ubuntu application bug.

Concerning the last point, you should know that their is an issue repport openned on the X / xorg bug tracker system here:
=========================================
http://bugs.freedesktop.org/show_bug.cgi?id=25220
=========================================

If anyone have any usefull informations to add about this bug, it would be better to do it there instead of here.

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.

Download full text (5.5 KiB)

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...

Read more...

Sandro Mani (sandromani) wrote :

Tralalalala:
1. I don't know if you ever coded or worked on a larger project, but I can guarantee you that no matter how good the documentation of a program is you still first have to read through the whole code if it wasn't you writing it. A program consists of the written part which everyone can see and more importantly of the logic behind it that the programmer developed in his mind, it is very hard that any text can give you complete insight of what was going on inside the programmer's head when he was writing the program.
2. "I don't give a fuck about that bugs. Fix it yourself.": first of all keep in mind that many proprietary companies really don't give a damn about bugs reported by normal users since they are not worth it economically. They often do not even provide you (as a normal user) with any insight about what issues are known with their software, what's the status and so on. Here you will find plenty of examples which show that developers listen to you no matter who you are. And again, developers are not your slaves. As a developer there is always a certain amount of passion involved in creating a program, hence it is quite unlikely that they will remain indifferent to a major flaw, but you must also respect the fact that they make choices what is for them higher priority that may be different than what you might want. And in this particular case it is not even clear if it is X that should be fixed, since the specification is actually clear and it's the programs that in some cases don't implement it. And keep in mind, it is very likely much easier to fix the bad behaving applications than to radically change a core part of the xserver, possibly causing other regressions that don't make you any happier.
3. Open-source software means that anyone actually has the possibility to contribute, which indeed DOES give you the possibility to improve something if you are not happy with the current situation. Again, it is highly unlikely that developers do not care, but since most of the work is done on a voluntary basis in their free time you should also respect their choices
4. Since you probably never donated anything to any project, while you are free to point out bugs, it is quite rude at best to call developers non-caring whatevers and such.

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?

LimCore (limcore) wrote :

pyrates,

you say "We don't want a bandaid solution or a work around" - what?

Well, we, the USERS - we DO WANT a working solution, even if it is "bandaid" or "work around".

Also, why this would be bad if all applications would rely on such external clipboard instead doing it better themselves? Then they can use developers time for other things that do NOT have an usable work around like percelite.

pyrates (pyrates18) wrote :

@LimCore

I don't think you understand the meaning of the definitions "band aid" and "work around". A "band aid" or "work around" means it's not properly fixed or only partially implemented. The implementation is not expandable. It actually creates more work in the end due to it's bad design.

Something that does not fix a problem but offers an alternative method to avoid it; usually a temporary solution to a software bug (from http://www.wordwebonline.com/en/WORKAROUND).

Now the work around in this case only handles text and users have to install manually. I don't want to have to remember to install something to get a working clipboard.

It also only works on gnome. For KDE, you gotta use klipper. So now we got 2 programs that are trying to do the same thing, therefore wasting development time because you gotta do it twice. And if there is another DE created, then we gotta develop an application like parcellite for that as well, again wasting developer time.

This is why fixing it at the level it was created at is so important. Where can you handle audio and video for instance? Files? All have to be re-implemented each time if it is not fixed at the level it was created at, which is now Xorg.

Anyone having to manage a software development project as well knows how important it is to first design something before you do any programming for it.

Dahaniel (dm-protzkeule) wrote :

Bug is persisting in Karmic and I agree that it is CRITICAL!
When I first switched to Linux I ran into this bug very often now I kind of learned to live with it (which doesn't make it better).

Michael Nagel (nailor) wrote :
Download full text (8.8 KiB)

Here is a log from IRC ubuntu-devel where Collin Watson said some things.
Bottom Line: you have to install a Clipboard Manager but Ubuntu is not currently planning to install one by default. Installing a Clipboard Manager is not seen as a workaround but as a solution.

Technically it is a bit more complicated than you might think (see information about SAVE_TARGETS) and what GNOME currently does is including a Clipboard Manager on an Opt-In basis (that is your application can request to make use of the Clipboard Manager) thus leaving all legacy applications, KED applications, Desktop agnostic applications remain broken.

(18:53:24) The topic for #ubuntu-devel is: Lucid Alpha 2 released | Archive: open | MoM running (but use bzr!) | Development of Ubuntu (not support, not app development on Ubuntu) | #ubuntu for support and general discussion for dapper-karmic | #ubuntu-motu for getting involved in development | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://wiki.ubuntu.com/HelpingWithBugs
(19:01:21) nailora: there is bug 11334 that i am following for quite some time because it bugs me, too :) it is about what happens to the clipboard contents when an application quits. discussion has become more and more off-topic, and there seems to be a lack of developer participation. i'd like to know how to proceed with this...
(19:01:25) ubottu: Launchpad bug 11334 in ubuntu "MASTER Copy-Paste doesn't work if the source is closed before the paste" [Wishlist,Confirmed] https://launchpad.net/bugs/11334
(19:04:26) nailora: it is somewhat broken deep within the x-server (or the spec the x-server follows). or nearly all application just do not to the right thing as it can be fixed on application level, too. but this will not happen for all legacy applications. clipboard managers are not the solution but a workaround, but waiting for a solution in x.org/the spec x.org follows will take lots of time and a workaround might be good in the meantime... ...
(19:04:51) genii: I have Intel Pro/1000 XF (fibre optic card) ethtool is reporting only 1000 Base T (copper) capability (when should be 1000 Base FX). Is there some known prob/fix for the e1000 driver?
(19:05:21) cjwatson: nailora: workaround: use a clipboard manager application, that takes a copy of the clipboard contents and stashes it
(19:06:28) ***pitti reenables hourly WI tracker updates, sorry
(19:06:42) cjwatson: it's an X design issue, I wouldn't expect it to be fixed any other way
(19:06:57) cjwatson: indeed I don't think it is *fixable* any other way
(19:07:00) nailora: cjwatson: i know that and i do it it that way personally. but arguably this should "just work" for everyone. that would require a solution that could be included in the default installation
(19:07:27) cjwatson: if you're starting from the position that "clipboard managers are not the solution but a workaround", then there is no other option except to wait for (or participate in?) an X design fix
(19:08:43) cjwatson: X clipboard clients ask the clipboard owner (an application) for clipboard contents when they need it, and if the application exits then there's no owner to respond; there's no way that can be an appli...

Read more...

Rafal-maj-it (rafal-maj-it) wrote :

Thanks guys - finally the bug is fixed and backported everywhere :)

April Fools' day! Sorry guys

Veeeeeeeeery good!

Bye

> Thanks guys - finally the bug is fixed and backported everywhere :)
>
>
>
>
>
> April Fools' day! Sorry guys
>
> --
> MASTER Copy-Paste doesn't work if the source is closed before the paste
> https://bugs.launchpad.net/bugs/11334
> You received this bug notification because you are a direct subscriber
> of a duplicate bug.
>

Bartolomeo Nicolotti
v.Fossano 18
12040 Montanera (CN)
<email address hidden>
http://www.bartolomeonicolotti.it

Hell Pé (hellpe) on 2010-04-01
description: updated
Tralalalala (tralalalala) wrote :

Rafal-maj-it wrote 8 hours ago:
"Thanks guys - finally the bug is fixed and backported everywhere :)

April Fools' day! Sorry guys"

Not a realistic joke at all, because this bug won't be fixed before the year 2020 and probably won't be fixed at all.

*** Bug 563913 has been marked as a duplicate of this bug. ***

Nowres Rafed (nss-zpeedzter) wrote :

this bugs exists also in code::blocks 8.02

J Bruni (jbruni) wrote :

I don't want to wait for Zealous Zebu (Ubuntu 17.04) to see this resolved.

As a user, I want to use copy/paste being able to paste from a closed application. (Why leave it open, then go back only to close it?)

As a developer, I work with PHP doing simple web applications. I don't know about complex details on X-server using C language.

Anyway, I just want to contribute by sharing here some information about WHERE is the SOURCE CODE that deals with this issue and how to GET it. Others, like me, may want to "poke around" and, perhaps, ...help to develop a solution!

The package name is xserver-xorg-core

We can get the source code with the following command:

apt-get source xserver-xorg-core

I am using Lucid Lynx, and apt-get brought me Xserver 1.7.6 source code files.

Alternatively, if "git" is installed, repository can be cloned with the following command:

git clone git://git.debian.org/git/pkg-xorg/xserver/xorg-server

We can find several references to "clipboard" using "grep":

cd xorg-server*
grep -r "clipboard" *

Most important files seems to be:

hw/xwin/winclipboard.h
hw/xwin/winclipboardinit.c
hw/xwin/winclipboardthread.c
hw/xwin/winclipboardwndproc.c
hw/xwin/winclipboardxevents.c
hw/xwin/winclipboardwrappers.c
hw/xquartz/pbproxy/x-selection.m

Comprehensive information on how to compile Xserver can be found here: http://www.x.org/wiki/CompileXserverManually

I am not sure, but it seems that the latest developer who made changes in the Xserver clipboard management code is Harold L. Hunt. So, if someone wants to resolve this, I recommend asking directions to him - http://huntharo.com - huntharo (at) gmail.com

Another developer that seems to have dealed with Xserver clipboard issues is Colin Harrison - http://sourceforge.net/users/colinharrison

Hope this helps...

Good luck for us all!

Kip Warner (kip) wrote :

"I don't want to wait for Zealous Zebu (Ubuntu 17.04) to see this resolved."

ROFLMAO!!!

J Bruni (jbruni) wrote :

Wondering aloud....

If the application that owns the clipboard provides its contents (unavailable once it is closed)...

What if we always make Xserver itself be this application (the owner of the contents), and thus always serve its contents (always available!)

i.e., when the user copies (CTRL+C) or cuts (CTRL+V) instead of stopping at the point where the current application is "flagged as owner"... just go ahead and transfer contents + ownership to Xserver.... so, when the user pastes (CTRL+V) elsewhere, it will retrieve contents from Xserver... it doesn't matter if source application is opened or closed...

Makes sense?

Do we need a more complicated "design" for the solution? Or can we move forward by finding out how to implement the idea above?

Download full text (3.8 KiB)

Its would be a great solution but i think that its a solution that requires
a lot of work, and would be incompatible with other distributions.
Somebody knows the internal structure of XServer to say if i am in a error?

2010/5/24 J Bruni <email address hidden>

> Wondering aloud....
>
> If the application that owns the clipboard provides its contents
> (unavailable once it is closed)...
>
> What if we always make Xserver itself be this application (the owner of
> the contents), and thus always serve its contents (always available!)
>
> i.e., when the user copies (CTRL+C) or cuts (CTRL+V) instead of stopping
> at the point where the current application is "flagged as owner"... just
> go ahead and transfer contents + ownership to Xserver.... so, when the
> user pastes (CTRL+V) elsewhere, it will retrieve contents from
> Xserver... it doesn't matter if source application is opened or
> closed...
>
> Makes sense?
>
> Do we need a more complicated "design" for the solution? Or can we move
> forward by finding out how to implement the idea above?
>
> --
> MASTER Copy-Paste doesn't work if the source is closed before the paste
> https://bugs.launchpad.net/bugs/11334
> You received this bug notification because you are a direct subscriber
> of a duplicate bug.
>
> Status in One Hundred Paper Cuts: Invalid
> Status in X.Org X server: Confirmed
> Status in Ubuntu: Confirmed
>
> Bug description:
> ===+++ _____________________ ! ALL USERS ! _____________________ +++===
> ===+++ READ THIS BEFORE MAKING A COMMENT OR MODIFICATION +++===
>
> IMPORTANT 1: Please see the WORKAROUND a few lines below.
>
> IMPORTANT 2: Please don't post any "me too message"; use the "Does this bug
> affect you?" feature you can find a bit above this bug description on
> launchpad.
>
> IMPORTANT 3: Do not post anything if you haven't read all comments to
> verify that your point hasn't been made. If you feel tempted to stop reading
> because there are too many messages, that is a strong indicator that you
> shouldn't add even more comments. Developers have a tough time to find
> anything if you post redundant stuff. So please abstain from doing that.
>
> *** WORKAROUND ***
> ---------------------------
> Install klipper, glipper, parcellite or xfce4-clipman
>
> --------------------------------------------
>
> When I copy (Ctrl + C, or right click and "Copy") text from somewhere and
> after that close the program where it is, the clipboard gets empty.
>
> Steps to reproduce in gedit :
> 1. Pick any text field that supports copying, copy some text.
> 2. Paste into any other text field.
> 3. It works.
> 4. Close the source window or program.
> 5. Paste now does nothing.
>
> This bug will happen in any application that doesn't comply with the
> clipboard specification from FreeDesktop.
> http://www.freedesktop.org/wiki/ClipboardManager
>
> There was also previous considerations about improving xserver-xorg
> clipboard, which would reduce adaptation work from upstream projects to
> comply with the specification.
> Xorg : https://bugs.freedesktop.org/show_bug.cgi?id=25220
> http://www.x.org/wiki/CutAndPaste
>
> ******** Actual Status : ********
> ----- Not fixed : ------
> OpenOffi...

Read more...

Rickard Närström (riccetn) wrote :

There is already a solution for this, it's designed and ready and it is currently being implementing it in applications (one by one). This already works with many applications (some listed in the description).

The new specs for this is available at http://www.freedesktop.org/wiki/ClipboardManager (which is also linked in the the description).

Michael Nagel (nailor) wrote :
Download full text (4.4 KiB)

Making the xserver the owner of all content is pretty much the same as using a clipboard manager and making that the owner of all content. There are working clipboard managers ready to be installed from the repository -- namely klipper, glipper and parcellite . they are the more or less official workaround as suggested by collin watson (see comment # 207 ) why none of these clipboard managers is installed by default goes beyond my understanding.

There is one problem with these clipboard manager that causes problems with programs like e.g. the gimp and other, that is quite hard to fix properly.

When exporting some lines of text to the clipboard the suggested approach (just grabbing it when it is exported) will work just fine. With binary data like images the problem gets more complicated because now you have a lot more data and it potentially contains lots of troublesome bits (nullbytes and the like) that must not crash nor confuse your clipboard manager. but that is pretty much solved by current clipboard mangers, too.

The real problem is about nonstatic data. In the above examples the content was present in the source application and you only had to copy it away from there. The clipboard offers functionality to create the data on demand. For example you could work on some vector graphic in inkscape and copy and paste the data to gimp where it would arrive as pixel data. The pixel data is only created when you paste it somewhere. So you can copy a hundred times and paste only the last copy, then only that version will be converted to pixel data. That is the clipboard basically asks your application to provide some content and it is up to you if you answer with some existing data or generate some new data just to satisfy that request. When that generation is expensive it is not practicable to do it every time something is offered to the clipboard but only when something is requested from the clipboard. But a clipboard manager basically request the data every time some data is offered to the clipboard invalidating that optimization and causing a lot of data to be generated and transferred.

That overhead might be tolerated, too. But to further complicate matters:
When exporting something to the clipboard you don't export something fixed. Fixed means you already decided about what to export (although you might not yet have created it yet -- see above). No, you say that you offer "plain text", "rich text", "binary data" or "a nice picture". When pasting the application does not request the "contents of the clipboard" but says it understands "plain text", "vector graphics", "binary data" and "wave sounds". Now some arbitration takes place and the applications agree on transferring "plain text" (or "binary data" whatever is better for some definition of better). Thus it is not even clear what a clipboard manager should grab when an application offers some data for export to the clipboard. It might grab all the offered datastreams but that obviously means some heavy overhead...

One thing gnome does is to offer a clipboard manager where your application can store the things it offers to the clipboard when it exits. Control over the clipboard is ...

Read more...

ktulu77 (ktulu-highwaytoacdc) wrote :
Download full text (6.0 KiB)

Michael Nagel, I have read carefully your comment and I think you are
right for the non-static data and it might be also complicated to deal
with the history of clipboard managers and this kind of data also...
We could have a history per clipboard type, the text history would
have more items than bitmap type, etc.

But there is some problems with the clipboard manager workaround :

Parcellite -> it is not a Gnome application (does not use gconf, stay
in the notification area, etc) and it is not going to be maintained
anymore (see parcellite website)

Glipper -> dead for three years, and it is written in the mailing list
of the project that it won't be maintained anymore

If we want to have a clipboard manager integrated to distributions,
the first thing to have is maybe a well maintained application for
that first ?

I think we should continue the development of Glipper because it is
written in python and it is easy to patch, maintain and it is also a
real gnome application. Plugins are also very easy to add.

Is someone interesting in making a fork or something about Glipper ?
Once we have a maintained clipboard manager, we could add more
features like the ability to manage different kinds of contents of the
clipboard.

2010/5/24, Michael Nagel <email address hidden>:
> Making the xserver the owner of all content is pretty much the same as
> using a clipboard manager and making that the owner of all content.
> There are working clipboard managers ready to be installed from the
> repository -- namely klipper, glipper and parcellite . they are the more
> or less official workaround as suggested by collin watson (see comment #
> 207 ) why none of these clipboard managers is installed by default goes
> beyond my understanding.
>
> There is one problem with these clipboard manager that causes problems
> with programs like e.g. the gimp and other, that is quite hard to fix
> properly.
>
> When exporting some lines of text to the clipboard the suggested
> approach (just grabbing it when it is exported) will work just fine.
> With binary data like images the problem gets more complicated because
> now you have a lot more data and it potentially contains lots of
> troublesome bits (nullbytes and the like) that must not crash nor
> confuse your clipboard manager. but that is pretty much solved by
> current clipboard mangers, too.
>
> The real problem is about nonstatic data. In the above examples the
> content was present in the source application and you only had to copy
> it away from there. The clipboard offers functionality to create the
> data on demand. For example you could work on some vector graphic in
> inkscape and copy and paste the data to gimp where it would arrive as
> pixel data. The pixel data is only created when you paste it somewhere.
> So you can copy a hundred times and paste only the last copy, then only
> that version will be converted to pixel data. That is the clipboard
> basically asks your application to provide some content and it is up to
> you if you answer with some existing data or generate some new data just
> to satisfy that request. When that generation is expensive it is not
> practicable to do it every time so...

Read more...

pyrates (pyrates18) wrote :

I've been watching the comments carefully over the past few days and we seem to be falling into the same traps previous comments already have mentioned but we can't do:

1. It's already spec'd out on a per application basis on how to properly implement it on linux.
-this spec has been around for years and we only have a few applications that follow it
-the reason why most linux developers don't follow it is because they don't like it
-when they develop versions of their software on windows or mac os x, they don't need to jump through these extra hoops to get it working with the clipboard
-so because they don't have to do it in windows and mac os x, they feel they shouldn't have to on linux either
-remember developers are inherently lazy and anything that makes it easier to work with your platform, they will use
-this implementation makes it harder to work with linux and they clearly don't like the spec
2. We got a clipboard manager already, just install that
-this is a bandaid solution
-only works with text
-not installed by default
-there must be one developed for each DE and its the equivalent of reinventing the wheel over and over which seems to occur in open source quite often I notice
3. Implement and fix it on Xorg itself
-this is the right solution as it's where the clipboard exists
-won't need multiple versions for each DE out there as each DE would immediately get it
-needs to be spec'd out as it's only an idea right now
-reasons why old school linux developers won't implement it and a new generation of linux developers will have to work on it:
http://elliotth.blogspot.com/2008/08/desktop-linux-suckage-clipboard.html

Changed in epiphany:
status: Unknown → New
Changed in empathy:
status: Unknown → New
Changed in abiword:
status: Unknown → Confirmed
srgb (work-serge) wrote :

The most complicated part of the issue described here is following:

"Only application knows how to handle its buffer properly, hence when it's closed - nobody can paste it."

The example can be quite simple: you enter formatted text, pictures and tables in OOo' Writer and then select-all and paste it to:
* notepad app (like gedit/kate/gvim/...) - only text is pasted
* bitmap editor (like gpaint/kpaint/...) - the whole buffer is represented as picture and pasted on the canvas
* another OOo' Writer window - the original formatting is kept (tables are tables, text is text, pictures are pictures...)

Everything is handled by OOo' itself. No clipboard manager will ever be able to the same work after OOo is closed.
... And it's not needed! Why reinvent the wheel?!

This is my idea on how to implement it properly:

"Take the code that handles the buffer off the application (like OOo and others), and place it into the X-server. As a plugin.
When OOo is closed, it's plugin is still present and works with X-server to process 'paste'-requests."

PS. OOo is just an example, take any other complex app, like dia/gimp/firefox/... instead if you wish.

pros/cons:
+ such a plugin is developed by developers of the original app and not by bystanders: less time to deliver the working plugin than adding support of strange source-buffer-type to clipboard manager
+ the plugin is no more than just a replacement of "paste"-handler from within the app to the X-server
+ no need to maintain "clipboard managers" for each DE
+ it's not a band-aid solution: it works on all permutations of "source"/"target" type pairs
+ some plugins may support more than one "source" applications (no need to write different plugins for simple notepad-applications, the same - for all simple raster graphic editors)
- need to create a clear spec and ask developers to follow it

Isn't it a good idea? :)

Changed in openoffice:
status: Unknown → Confirmed
Guilhem (logik-free) wrote :

Rather than trying to implement a plugin system like srgb proposed, which IMHO might get very complicated as it involves a lot of persons/programs, I think the spec could slightly be changed :

From http://www.freedesktop.org/wiki/ClipboardManager
"Responsibilities of clipboard owners
If a client needs to exit while owning the CLIPBOARD selection, it should request the clipboard manager to take over the ownership of the clipboard, using the SAVE_TARGETS mechanism. If there is no clipboard manager, or if the SAVE_TARGETS conversion fails, the application should simply exit."

Change it to :

"Responsibilities of clipboard owners
If a client needs to exit while owning the CLIPBOARD selection, the clipboard manager should acquire right away all targets the client offers (limited by a sized-based limit), so the clipboard manager takes over the ownership of the clipboard, using the SAVE_TARGETS mechanism. If there is no clipboard manager, or if the SAVE_TARGETS conversion fails, the application should simply exit."

Anyways, I think that if every application (mozilla, gimp, ooo, etc.) developpers started modifing their sources to follow the orginal specs is because they know Xorg developpers won't make the move themselves to modify the specs...

Changed in empathy:
status: New → Confirmed
pyrates (pyrates18) wrote :

This list is gonna get pretty long if we start listing out every single app that doesn't follow the specification. The reason being that most of them don't follow it. And will the Ubuntu developers now have to keep adding in the "follow the clipboard specification" fix every time one of these applications gets updated by the software developer because we all know they don't like this specification. So why is the Xorg team trying to force this specification down everyone else's throats?

Changed in xulrunner:
status: Unknown → Fix Released
Vistaus (djmusic121) wrote :

Why is xulrunner set to Fix Released? The bug's still there. Please change it back until it really is fixed.

Changed in hundredpapercuts:
status: Invalid → Confirmed
Rickard Närström (riccetn) wrote :

@Visraus: This is fixed in upstream xulrunner, and as the status you see here track the upstream bug report it is marked as "Fix Released". As of 100 paper cuts, this has already been denied for that project several times mostly with motivations that it is to complicated to fix for a paper cut.

Changed in hundredpapercuts:
status: Confirmed → Invalid
Changed in gtk:
status: Unknown → New
Sarah Strong (sarahstrong) wrote :

I'm tackling this bug for Ubuntu through Google Summer of Code 2010. You can check out a summary of the problem at https://wiki.ubuntu.com/ClipboardPersistence. If an application you develop for is listed as broken there and you're interested in helping a novice developer implement the ClipboardManager specification fix, please drop me a line.

pyrates (pyrates18) wrote :

Welcome Sarah. If you read the comments here, I don't think people want it fixed on a per application basis. Linux developers coming from windows and mac os x, don't want to have to put in extra work on linux just to get the clipboard working with their app. They want it taken care of for them.

What they would like is for it to be fixed in Xorg. The amount of time that it takes to transfer data from the hard drive to memory is almost negligible. The excuse that it saves time may have been true in 1993, but that is no longer the case.

If you want an overview on what's wrong with the clipboard that gives more detail then the Ubuntu wiki has, read here:

http://elliotth.blogspot.com/2008/08/desktop-linux-suckage-clipboard.html

Now in terms of implementing, a number of things should be accomplished:

1. Retain clipboard data in Xorg itself. This fixes the problem in all DE's.
2. Identify the type of data stored in the clipboard so that a program expecting text and gets another type like part of an mp3, knows to ignore it.
3. Reserve shortcuts like ctrl+c cltrl+v and ctrl+x for the clipboard by default. Allow programs to override them if they wish. IE a terminal app.
4. Remove the right click as paste method and selection copy method. But once again allow programs to implement them if they wish.
5. When it's an actual file or directory, store the file location or directory location only but identify the data type as a file. As this would be too big to store in the clipboard. This we know won't go away easily since the shell is constantly running.
6. If a program exits and was holding a large amount of data in the clipboard, ask the user if they wish to remove it from the clipboard up on exit.
7. There should be 3 data types for the clipboard at minimum. 1st is text, 2nd data, and 3rd a file or directory. The 2nd one, data, could be broke down further. For example copying data from a program for audio might be in a format that only that program supports. So each program would have to specify the kinds of data from the clipboard it could accept. This way if you try to paste a data type from the clipboard that the current program doesn't recognize, it can simply ignore it.

That's all I can think of for now.

Patrick Rynhart (prynhart) wrote :

It would be good if images captured by gnome-screenshot could be made to persist after this application is closed. Details of this issue (which has been marked as a dup of this bug) is at

https://bugs.launchpad.net/ubuntu/+source/gnome-utils/+bug/591498

Thank you,

Patrick

Changed in tomboy:
status: Unknown → New
3esmit (3esmit) wrote :
Download full text (4.2 KiB)

There sould be a type of clipboard that references de opened program itself,
to keep also the old style, since some programs like programs suite (i.e.
adobe creative suite) have many types of data that it can be copy and pasted
as objects that one program grabs directally from other (i.e. copy a
photoshop layer to illustrator, the layers may be there in illustrator,
since it just got the same memory reference to the same generic data object)

By default, the XServer threats the good sense way for all programs that
just didnt care about the clipboard managing.

I like selection, I just wish I could reselect other text and drop the
selection over it (maybe a special modifier key?)
Selection should be 1. activated by user. 2. possiblity to program choose
ignore it when it wishes so.

Thanks all.

2010/6/19 Bug Watch Updater <email address hidden>

> ** Changed in: tomboy
> Status: Unknown => New
>
> --
> MASTER Copy-Paste doesn't work if the source is closed before the paste
> https://bugs.launchpad.net/bugs/11334
> You received this bug notification because you are a direct subscriber
> of the bug.
>
> Status in AbiWord: Confirmed
> Status in ChmSee: Unknown
> Status in Chromium Browser: Unknown
> Status in Eclipse: Unknown
> Status in Chat app, and Telepathy user interface: Confirmed
> Status in Epiphany - Clone of BoulderDash Game: New
> Status in gnome-utils - GNOME Desktop Utilities: New
> Status in GnuCash - Finance manager: Unknown
> Status in GTK+ GUI Toolkit: New
> Status in One Hundred Paper Cuts: Invalid
> Status in Inkscape: A Vector Drawing Tool: New
> Status in The OpenOffice.org Suite: Confirmed
> Status in Tomboy: New
> Status in X.Org X server: Confirmed
> Status in XUL + XPCOM application runner: Fix Released
> Status in Ubuntu: Confirmed
>
> Bug description:
> ===+++ _____________________ ! ALL USERS ! _____________________ +++===
> ===+++ READ THIS BEFORE MAKING A COMMENT OR MODIFICATION +++===
>
> IMPORTANT 1: Please see the WORKAROUND a few lines below.
>
> IMPORTANT 2: Please don't post any "me too message"; use the "Does this bug
> affect you?" feature you can find a bit above this bug description on
> launchpad.
>
> IMPORTANT 3: Do not post anything if you haven't read all comments to
> verify that your point hasn't been made. If you feel tempted to stop reading
> because there are too many messages, that is a strong indicator that you
> shouldn't add even more comments. Developers have a tough time to find
> anything if you post redundant stuff. So please abstain from doing that.
>
> *** WORKAROUND ***
> ---------------------------
> Install klipper, glipper, parcellite or xfce4-clipman
>
> --------------------------------------------
>
> When I copy (Ctrl + C, or right click and "Copy") text from somewhere and
> after that close the program where it is, the clipboard gets empty.
>
> Steps to reproduce in gedit :
> 1. Pick any text field that supports copying, copy some text.
> 2. Paste into any other text field.
> 3. It works.
> 4. Close the source window or program.
> 5. Paste now does nothing.
>
> This bug will happen in any application that doesn't comply with the
> clipboard specification from FreeDes...

Read more...

Changed in empathy:
status: Confirmed → Incomplete
Changed in empathy:
status: Incomplete → Confirmed
Ivanka Majic (ivanka) on 2010-07-06
tags: added: rhubarb
Changed in empathy:
status: Confirmed → Invalid

Another copy-paste problem...

I'm using evolution as mail client at work. The problem is that the mails I send are not visible on some outlook or send it in loop, but...

The mail server we use is Zimbra, that has a web-mail, so I use it to send mails to someone i know as a wonderful outlook, but...

If I've written something in evolution and then I try to copy-past the body from evolution to the zimbra compose form in firefox, I cannot, but

if I open gedit, then I paste to gedit then select, then copy then paste to zimbra composer it works!

wonderful how simple is to send a mail from ubuntu to windows (this is probably due to a but in outlook, of course...)!

Ubuntu 8.04 (I haven't had time/courage to upgrade to 10.4 LTS)
Evolution 2.22.3.1
Zimbra ?

many thanks!

bye

If we take it to branches we need bug 518249 and bug 531580 too.

I have this problem on Windows Vista Home Premium SP2 English. Firefox 3.6.8 Final English. Copy url from adresbar, restart firefox, then paste copied url, and clipboard is empty...

Marc, this particular bug is Linux-specific. You should file a new one if you happen to have this same problem on Windows. Clipboard implementations are completely different among different operating systems, so Windows issues are totally irrelevant in this Linux bug.

(In reply to comment #52)
> Marc, this particular bug is Linux-specific. You should file a new one if you
> happen to have this same problem on Windows. Clipboard implementations are
> completely different among different operating systems, so Windows issues are
> totally irrelevant in this Linux bug.

Ok, thanks :)

Created attachment 461511
1.9.2 version

Comment on attachment 461511
1.9.2 version

We will not be taking this for .9. Moving approval request forward.

Changed in gtk:
status: New → Invalid

Changed the GTK+ upstream bug because the precedent has been marked as a duplicate.

description: updated
description: updated

There is an unfixed dependency (bug 531580) and a fixed dependency (bug 518249) that depends on an unfixed bug (bug 552449).

Until those are resolved we can't take this on the branches.

jazzynico (jazzynico) on 2010-08-29
Changed in inkscape:
importance: Undecided → Low
status: New → Confirmed

Unsubscribing the Papercutters team.

affects: hundredpapercuts → null
Changed in xorg-server:
importance: Unknown → High
Changed in gtk:
importance: Unknown → Medium
status: Invalid → Confirmed
Changed in gnucash:
importance: Unknown → Medium
status: Unknown → Confirmed
Changed in empathy:
importance: Unknown → Medium
status: Invalid → Unknown
Changed in epiphany:
importance: Unknown → Medium
Changed in tomboy:
importance: Unknown → Medium
Changed in xulrunner:
importance: Unknown → Medium

Contrary to what is stated in the description (under "status"/"fixed") it is NOT fixed in Firefox.
Copy from firefox, then close firefox, then paste into another program, doesn't paste.

FMaz (fmaz008) wrote :

Maybe that's totally offtopic, but aside from Windows, how other *nix distributions are handling the problem ?

This bug is going on for a really long time now, and I think every time the problem is looked at, the qualified people say it's a design problem. Maybe we should check somewhere else to have some fresh idea ?

my 2 cents.

It's fixed in Firefox 4, of which a beta will hit Natty soon. There are
some upstream blockers on getting it into Firefox 3.6.

On 11/16/2010 12:42 PM, matteo sisti sette wrote:
> Contrary to what is stated in the description (under "status"/"fixed") it is NOT fixed in Firefox.
> Copy from firefox, then close firefox, then paste into another program, doesn't paste.
>

Changed in xorg-server:
importance: High → Unknown
Changed in webkit:
status: Unknown → Fix Released
Changed in abiword:
importance: Unknown → Medium
Changed in webkit:
importance: Unknown → Medium
Changed in xorg-server:
importance: Unknown → High
description: updated
Slated (ubuntu-slated) wrote :

X11 was not designed to have a persistent clipboard, deferring this functionality to elsewhere - typically the window manager, or some utility running thereon. X11 was designed to be modular, like everything else in *NIX, and AFAIAC this is a good thing. Consider the issues of resource overheads and security for a persistent plaintext clipboard, and how such a thing should not be a default element of the core of any window system.

Conversely, Microsoft Windows lacks any native primary selection buffer (copy-on-select), and the middle-click-paste function, without using an add-on utility, a fact I found intolerable and deeply frustrating, back in the days I used Windows.

If I had to choose between having a native persistent clipboard, or the copy-on-select/middle-click-paste function of X11, I'd pick the X11 way every time. The clipboard was only ever meant to be transient, so using it like some sort of notepad is broken behaviour, IMO. If you need such persistent notes, install a text editor, and save your notes to a file.

For those who really insist on a persistent clipboard, there are plenty of utilities for that.

pyrates (pyrates18) wrote :
Download full text (3.3 KiB)

This here is the problem with linux on the desktop. You have programmers like Slated here thinking inside a very narrow definition. He wants X11, now Xorg, to be modular at the cost of convenience. He's willing to put up with inadequacies like this just so it remains in his narrow definition of what it should do. And your trying to connect the clipboard with security doesn't jive. Linux I find on the servers I run gets updated just as often as windows does.

I find the copy on select and middle click paste functionality abhorring. It is so error prone that only those who specifically know what they are doing, programmers and advanced linux users, can use it. And the only reason why it was implemented the way it was, was because they didn't want to change the terminal commands ctrl+c and they wanted it to work in a terminal first and that should be how it should work elsewhere. And the people who could implement it refuse to because they don't like it. They instead in their arrogant way, assume programmers who are use to the method that windows and mac os x do to work with the clipboard, think they will change their ways just to create their app on linux. Seeing the number of applications that don't comply with this goes to show that those programmers of windows and mac os x refuse to give in. That they want the clipboard to be just like it is on windows and mac os x. Telling them they need to add low level access just to deal with the clipboard on linux is stupid. All they should need to worry about is copying the data to the clipboard. The clipboard should worry about keeping this data. Not the app that the data was copied from.

And besides, X11 and Xorg is ancient. It was dropped by google on android. Ubuntu and Fedora are moving away from it to wayland. it's just a mess of patches of kludge fixes that it's beyond saving. You can't implement anything modern on it cleanly without it ending up being a kludge. No one really uses the remote network capabilities of it anymore. It being modular has actually hurt it. And besides, it's not the 1980's anymore. We got computers that are way more powerful then that with a lot more memory that can easily deal with a persistent clipboard. So it's time to get away from that. It's what end users are use to. Don't be afraid to use the resources you are given.

And the temporary solution of running a program to fix the clipboard is a problem in itself. You need to install it and most of the time they only support text. What about video, audio and other types of binary data? This was known about in 1993 and in a couple years it will be 20 years since the problem was known about. To say open source moves rapidly isn't always true when it comes to features end users want and programmers don't care to implement because no one is paying them money to implement it.

Ubuntu has done a good job of making things easier but these fundamental features need to be their. That's how you'll become mainstream. I kept hearing every year from 2000-2010 that this year was gonna be the year of linux on the desktop. Well it hasn't happened. And the typical back pedal response was that we don't...

Read more...

Download full text (7.3 KiB)

Ok so I have a little free time on my hands. Hope I have enough programming
experience to at least come up with something useful.

As I can see, the applications that suffer from the bug are being fixed. So
the problem is related to different apps not complying to the standard. What
does this mean? Does this mean all the apps need to be changed or does some
change need to be made in Xorg?

Cris

On Sat, Mar 5, 2011 at 5:30 AM, pyrates <email address hidden> wrote:

> This here is the problem with linux on the desktop. You have
> programmers like Slated here thinking inside a very narrow definition.
> He wants X11, now Xorg, to be modular at the cost of convenience. He's
> willing to put up with inadequacies like this just so it remains in his
> narrow definition of what it should do. And your trying to connect the
> clipboard with security doesn't jive. Linux I find on the servers I run
> gets updated just as often as windows does.
>
> I find the copy on select and middle click paste functionality
> abhorring. It is so error prone that only those who specifically know
> what they are doing, programmers and advanced linux users, can use it.
> And the only reason why it was implemented the way it was, was because
> they didn't want to change the terminal commands ctrl+c and they wanted
> it to work in a terminal first and that should be how it should work
> elsewhere. And the people who could implement it refuse to because they
> don't like it. They instead in their arrogant way, assume programmers
> who are use to the method that windows and mac os x do to work with the
> clipboard, think they will change their ways just to create their app on
> linux. Seeing the number of applications that don't comply with this
> goes to show that those programmers of windows and mac os x refuse to
> give in. That they want the clipboard to be just like it is on windows
> and mac os x. Telling them they need to add low level access just to
> deal with the clipboard on linux is stupid. All they should need to
> worry about is copying the data to the clipboard. The clipboard should
> worry about keeping this data. Not the app that the data was copied
> from.
>
> And besides, X11 and Xorg is ancient. It was dropped by google on
> android. Ubuntu and Fedora are moving away from it to wayland. it's
> just a mess of patches of kludge fixes that it's beyond saving. You
> can't implement anything modern on it cleanly without it ending up being
> a kludge. No one really uses the remote network capabilities of it
> anymore. It being modular has actually hurt it. And besides, it's not
> the 1980's anymore. We got computers that are way more powerful then
> that with a lot more memory that can easily deal with a persistent
> clipboard. So it's time to get away from that. It's what end users are
> use to. Don't be afraid to use the resources you are given.
>
> And the temporary solution of running a program to fix the clipboard is
> a problem in itself. You need to install it and most of the time they
> only support text. What about video, audio and other types of binary
> data? This was known about in 1993 and in a couple years it will be ...

Read more...

Tralalalala (tralalalala) wrote :
Download full text (3.6 KiB)

Slated, you're just another open source idiot who thinks open source programmers do everything the right way. In your opinion Linux does everything right and other operating systems are designed in a very bad and unsecure way. Those open source idiots do everything they can to defend Linux and open source. Even for the biggest and most stupid bugs they try to find a reason why it isn't a bug, but instead a great design feature of those open source programmers and of course the way it's implemented in Linux is way better than the way it's implemented in other operating systems.

Please, slated, use your brains. Everyone can see the Linux way of implementing copy / paste is the most stupid design error ever made in an operating system. Copy / paste has to be implemented in the core of every operating sysrtem! It's completely ridiculous to expect developers of every single application to implement support for the Linux way of copy / paste. A developer of an application shouldn't have to worry about implementing copy / paste into his application. This support has to be there out of the box. The operating system itself should handle this.

If Linux doesn't get core functionality like copy / paste done right, it'll never get more than 1% of market share. Every year you hear it's going to be the year of Linux on the desktop, but Linux has been hugging the 1% of market share for years now. The market share isn't growing and if Linux doesn't get these core features of an operating sytem implemented the right way, its market share will never exceed 1%. In the year 2053 Linux will still have a market share of 0.94% or something like that. Well, in my opinion that's already 0.94% too much market share. An operating system which sticks to ideas from the 1980's and is developed by people who think like slated just doesn't deserve any market share at all.

People, just use a proper operating system. Use Mac OS X. Every Linux distribution just sucks.

There's pyrates again, the only Launchpad member who uses his brains. The only person here on Launchpad who really knows what he's talking about. Again, you've written a really good comment and I couldn't agree more.

Kiki, to have this bug fixed like it needs to be fixed, there have to be made changes to Xorg. Fixing this bug for every single just isn't the right way to fix this bug. Actually it wouldn't even be a bug fix, but just a workaround to have those applications work without actually fixing the bug itself.

The workaround of implementing copy / paste in every application is completely ridiculous. There are thousands of applications which can be installed in Ubuntu. You can't implement this functionality in all of those applications. After all those years copy / paste has only been implemented in a couple of applications. There are thousands of applications left to be fixed. Besides those existing applications, there's the problem of new applications being released every year. Almost every new application which is released doesn't have copy / paste implemented. After a new application has been released users have to be complaining for years to have copy / paste implemented. Firefox is one of the most u...

Read more...

Sarah Strong (sarahstrong) wrote :
Download full text (11.6 KiB)

I tackled this bug a bit last summer for Ubuntu and Google Summer of
Code, focusing specifically on GTK+ programs. You can check out
https://wiki.ubuntu.com/ClipboardPersistence/ for some information on what's
happening and how to fix it. Please feel free to update that page if you
find anything that's out of date, and to email me if you're a programmer and
you have any questions.

On Fri, Mar 4, 2011 at 11:56 PM, Kiki <email address hidden> wrote:

> Ok so I have a little free time on my hands. Hope I have enough programming
> experience to at least come up with something useful.
>
> As I can see, the applications that suffer from the bug are being fixed. So
> the problem is related to different apps not complying to the standard.
> What
> does this mean? Does this mean all the apps need to be changed or does some
> change need to be made in Xorg?
>
> Cris
>
> On Sat, Mar 5, 2011 at 5:30 AM, pyrates <email address hidden>
> wrote:
>
> > This here is the problem with linux on the desktop. You have
> > programmers like Slated here thinking inside a very narrow definition.
> > He wants X11, now Xorg, to be modular at the cost of convenience. He's
> > willing to put up with inadequacies like this just so it remains in his
> > narrow definition of what it should do. And your trying to connect the
> > clipboard with security doesn't jive. Linux I find on the servers I run
> > gets updated just as often as windows does.
> >
> > I find the copy on select and middle click paste functionality
> > abhorring. It is so error prone that only those who specifically know
> > what they are doing, programmers and advanced linux users, can use it.
> > And the only reason why it was implemented the way it was, was because
> > they didn't want to change the terminal commands ctrl+c and they wanted
> > it to work in a terminal first and that should be how it should work
> > elsewhere. And the people who could implement it refuse to because they
> > don't like it. They instead in their arrogant way, assume programmers
> > who are use to the method that windows and mac os x do to work with the
> > clipboard, think they will change their ways just to create their app on
> > linux. Seeing the number of applications that don't comply with this
> > goes to show that those programmers of windows and mac os x refuse to
> > give in. That they want the clipboard to be just like it is on windows
> > and mac os x. Telling them they need to add low level access just to
> > deal with the clipboard on linux is stupid. All they should need to
> > worry about is copying the data to the clipboard. The clipboard should
> > worry about keeping this data. Not the app that the data was copied
> > from.
> >
> > And besides, X11 and Xorg is ancient. It was dropped by google on
> > android. Ubuntu and Fedora are moving away from it to wayland. it's
> > just a mess of patches of kludge fixes that it's beyond saving. You
> > can't implement anything modern on it cleanly without it ending up being
> > a kludge. No one really uses the remote network capabilities of it
> > anymore. It being modular has actually hurt it. And besides, it's not
> > the 1980's anymore. We go...

Dylan McCall (dylanmccall) wrote :

Please keep this on topic. This bug report is not about adding a clipboard
manager; it is about misbehaving clients which do not implement X's
clipboard stuff to it's fullest extent. There is no change to the accepted
system going on here; only bug fixes.

pyrates (pyrates18) wrote :

For those who want this implemented properly, which I believe should happen in wayland, go check it out here:

http://brainstorm.ubuntu.com/idea/27331/

And vote it up so that it gets implemented! :)

Endolith (endolith) wrote :

It's never going to be fixed the way it should be. Just switch to a working OS like Windows 7 and unsubscribe from these bugs. That's what I'm doing.

Slated (ubuntu-slated) wrote :

pyrates: "use to the method that windows and mac os x do".
Tralalalala: "open source idiot".
Endolith: "Just switch to a working OS like Windows 7".

Ladies and gentlemen, I give you the Ubuntu "community".

I seem to be in the wrong place. I came here looking for a GNU/Linux distro (am I allowed to say "GNU" on an Ubuntu site, or is that censored?), but apparently this is a Windows/Mac evangelism site.

So the question is, if you're all so enamoured with Windows and the Mac, why don't you just stick to those operating systems, instead of trying to pervert GNU/Linux into the very thing people switch to GNU/Linux to get away from?

Or is that too obvious?

Anyway, good luck fixing your "bug". May you and your Windows, erm, I mean "Linux" operating system be very happy together.

Etienne Perot (etienneperot) wrote :

> the very thing people switch to GNU/Linux to get away from

Have you ever heard about someone switching to Linux because they hate the way the clipboard works on Windows/OS X, and want to get away from that?

Let's stop this nonsense and get this bug fixed, ladies and gentlemen.

Endolith (endolith) wrote :

> I seem to be in the wrong place. I came here looking for a GNU/Linux distro (am I allowed to say "GNU" on an Ubuntu site, or is that censored?)

Ubuntu might not be the right OS for you. You might prefer something with "GNU" in the title and a 1970s command line instead of an interface, with a picture of RMS in the boot screen instead of a penguin. I don't see why all these people start using Ubuntu and then complain about how it's becoming too easy to use and too similar to other OSes. Just use a different distro! Stop trying to sabotage Ubuntu's success with archaic crap.

> So the question is, if you're all so enamoured with Windows and the Mac, why don't you just stick to those operating systems

No no no. I used Ubuntu for 4 years and I'm *fed up* with it, so I *switched* to Windows. I'm not *sticking* with it. I'm *switching* to it. Different.

> instead of trying to pervert GNU/Linux into the very thing people switch to GNU/Linux to get away from?

Yeah, people are switching to Linux in droves, and the primary reason is because the clipboard in Windows just works too damn well. What they're really craving is a clipboard that forgets everything when you close the app.

And why am I still getting notifications for this bug when I've unsubscribed from it and other duplicates? >:(

And why does Launchpad allow people to argue and leave advocacy comments and other irrelevant noise like this, which is then sent to every one of the subscribers? There should be a way for users to mod up or down the relevancy of comments, so the irrelevant ones are minimized and the bug listing isn't crapped up with 260 comments that don't help fix the bug.

pyrates (pyrates18) wrote :

Slated, thank you for your comment. You've just said what linux users say when they are confronted with bugs in their precious distro. That instead of fixing them, they write them off and tell the user to just not use it.

It's one extreme to another. From this is the year of the linux desktop, to if you don't like it go use something else because it's free and if you got it for free you got no right to complain about it.

I know it's a defense mechanism because that kind of response can only come from someone whose just had their reality shattered by a reasonable argument. When your entire belief system is suddenly shown be false or part of it is shown to be false, you can either accept it or rationalize it further so that it can again fit in your belief system. That's why some people's reasons here for not wanting this fixed are so predictable. You only can rationalize something so far.

I'm not sure why the Ubuntu programmers have left this bug open for the community. With the amount of people wanting it fixed, I don't know why they won't commit to fixing this properly. Maybe they are with wayland. I'd hope so.

Download full text (4.7 KiB)

Slated, please dont feed the trolls...

El , Slated <email address hidden> escribió:
> pyrates: "use to the method that windows and mac os x do".

> Tralalalala: "open source idiot".

> Endolith: "Just switch to a working OS like Windows 7".

> Ladies and gentlemen, I give you the Ubuntu "community".

> I seem to be in the wrong place. I came here looking for a GNU/Linux

> distro (am I allowed to say "GNU" on an Ubuntu site, or is that

> censored?), but apparently this is a Windows/Mac evangelism site.

> So the question is, if you're all so enamoured with Windows and the Mac,

> why don't you just stick to those operating systems, instead of trying

> to pervert GNU/Linux into the very thing people switch to GNU/Linux to

> get away from?

> Or is that too obvious?

> Anyway, good luck fixing your "bug". May you and your Windows, erm, I

> mean "Linux" operating system be very happy together.

> --

> You received this bug notification because you are a direct subscriber

> of a duplicate bug (528538).

> https://bugs.launchpad.net/bugs/11334

> Title:

> MASTER Copy-Paste doesn't work if the source is closed before the

> paste

> Status in AbiWord:

> Confirmed

> Status in ChmSee:

> Unknown

> Status in Chromium Browser:

> Unknown

> Status in Eclipse:

> Unknown

> Status in Chat app, and Telepathy user interface:

> Unknown

> Status in Epiphany - Clone of BoulderDash Game:

> New

> Status in gnome-utils - GNOME Desktop Utilities:

> New

> Status in GnuCash - Finance manager:

> Confirmed

> Status in GTK+ GUI Toolkit:

> Confirmed

> Status in Inkscape: A Vector Drawing Tool:

> Confirmed

> Status in NULL Project:

> Invalid

> Status in The OpenOffice.org Suite:

> Confirmed

> Status in Tomboy:

> New

> Status in Webkit Direct Port:

> Fix Released

> Status in X.Org X server:

> Confirmed

> Status in Xournal:

> New

> Status in XUL + XPCOM application runner:

> Fix Released

> Status in Ubuntu:

> Confirmed

> Bug description:

> ===+++ _____________________ ! ALL USERS ! _____________________ +++===

> ===+++ READ THIS BEFORE MAKING A COMMENT OR MODIFICATION +++===

> IMPORTANT 1: Please see the WORKAROUND a few lines below.

> IMPORTANT 2: Please don't post any "me too message"; use the "Does

> this bug affect you?" feature you can find a bit above this bug

> description on launchpad.

> IMPORTANT 3: Do not post anything if you haven't read all comments to

> verify that your point hasn't been made. If you feel tempted to stop

> reading because there are too many messages, that is a strong

> indicator that you shouldn't add even more comments. Developers have a

> tough time to find anything if you post redundant stuff. So please

> abstain from doing that.

> *** WORKAROUND ***

> ---------------------------

> Install klipper, glipper, parcellite or xfce4-clipman

> --------------------------------------------

> When I copy (Ctrl + C, or right click and "Copy") text from somewhere

> and after that c...

Read more...

Murray Cumming (murrayc) wrote :

Please stop the abuse. It is not helpful at all. Please see the code of conduct.

Tralalalala (tralalalala) wrote :

"Please stop the abuse. It is not helpful at all. Please see the code of conduct."

Like it's possible to post anything helpfull on this bug report. This bug isn't fixed after all those years and even in the year 2024 this bug will not be fixed. It's completely impossible to post anything helpfull here, because this bug (like so many other annoying bugs in Ubuntu (and Linux in general)) won't be fixed.

pyrates (pyrates18) wrote :

Just so we don't fill up this bug report anymore, here's a fresh start for people who don't want it implemented the way freedesktop.org has:

https://bugs.launchpad.net/ubuntu/+source/wayland/+bug/865885

But would rather have it implemented properly, instead of on a per app basis.

Changed in xorg-server:
status: Confirmed → Invalid
robbert (robbertvandendoorn) wrote :

For everyone who wants this bug to be fixed in this crappy, amateuristic operating system: It will never happen.

The only way to solve is this problem: Buy a Mac or install Windows.

I'm confident a big number of people who subscribed to this bug of clicked "Affects me too" have already solved this problem by just not using Linux anymore. Most people who try Linux, uninstall it again within a few months, because they get so annoyed by all those bugs.

I've tried and on ubuntu 8.04 it seems to work

Bye!

> For everyone who wants this bug to be fixed in this crappy, amateuristic
> operating system: It will never happen.
>
> The only way to solve is this problem: Buy a Mac or install Windows.
>
> I'm confident a big number of people who subscribed to this bug of
> clicked "Affects me too" have already solved this problem by just not
> using Linux anymore. Most people who try Linux, uninstall it again
> within a few months, because they get so annoyed by all those bugs.
>
> --
> You received this bug notification because you are subscribed to a
> duplicate bug report (430563).
> https://bugs.launchpad.net/bugs/11334
>
> Title:
> MASTER Copy-Paste doesn't work if the source is closed before the
> paste
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/abiword/+bug/11334/+subscriptions
>

Curtis Hovey (sinzui) on 2011-11-11
no longer affects: null

This is f****** ridiculous, more than 6 years, it can't take THAT long to fix this. I understand this is the way it is designed, but it is designed the wrong way if you can't paste after closing the source of the copy.
And importance should be at the very least "High"

skabbedabbeda (skabtrebge) wrote :

@matteo sisti sette (matteosistisette):

"Reported by Arandonohue on 2004-12-20". That's indeed more than 6 years, but it's even more than 7 years. Besides that, it's been more than 7 years the bug was reported on Ubuntu's Launchpad, but this bug is way older. Even before Ubuntu existed, this bug already existed and was to be found in Linux distributions which existed 10 years ago.

Don't expect this bug to be fixed, because developers just don't care about this bug. If you want to get rid of this bug, then there's only one solution: Don't use this crap anymore. Install Windows or buy a Mac (or try to install Mac OS X on a regular PC). That's the only solution.

My advice is to buy a Mac. I know they aren't cheap, but I did so and it works great. It's just absolutely gorgeous. Everything just works as it's supposed to.

Just get rid of Linux completely. Using another distribution isn't an option, because it's all the same crap. Linux is only good for servers which run without a GUI, it's just not designed for desktops. For your desktop there are only two operatings systems which really work: Windows and Mac OS X (although I'm so sure about the first one, but it's way better than any Linux distribution available.)

3esmit (3esmit) wrote :
Download full text (4.9 KiB)

Dear @skabbedabbeda

We like linux, we believe in an open source future, where open source
is the best. We want all to be perfect, we dont want Mac.

2012/1/26 skabbedabbeda <email address hidden>:
> @matteo sisti sette (matteosistisette):
>
> "Reported by Arandonohue on 2004-12-20". That's indeed more than 6
> years, but it's even more than 7 years. Besides that, it's been more
> than 7 years the bug was reported on Ubuntu's Launchpad, but this bug is
> way older. Even before Ubuntu existed, this bug already existed and was
> to be found in Linux distributions which existed 10 years ago.
>
> Don't expect this bug to be fixed, because developers just don't care
> about this bug. If you want to get rid of this bug, then there's only
> one solution: Don't use this crap anymore. Install Windows or buy a Mac
> (or try to install Mac OS X on a regular PC). That's the only solution.
>
> My advice is to buy a Mac. I know they aren't cheap, but I did so and it
> works great. It's just absolutely gorgeous. Everything just works as
> it's supposed to.
>
> Just get rid of Linux completely. Using another distribution isn't an
> option, because it's all the same crap. Linux is only good for servers
> which run without a GUI, it's just not designed for desktops. For your
> desktop there are only two operatings systems which really work: Windows
> and Mac OS X (although I'm so sure about the first one, but it's way
> better than any Linux distribution available.)
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/11334
>
> Title:
>  MASTER Copy-Paste doesn't work if the source is closed before the
>  paste
>
> Status in AbiWord:
>  Confirmed
> Status in ChmSee:
>  Unknown
> Status in Chromium Browser:
>  Unknown
> Status in Eclipse:
>  Unknown
> Status in Chat app, and Telepathy user interface:
>  Unknown
> Status in Epiphany - Clone of BoulderDash Game:
>  New
> Status in gnome-utils - GNOME Desktop Utilities:
>  New
> Status in GnuCash - Finance manager:
>  Confirmed
> Status in GTK+ GUI Toolkit:
>  Confirmed
> Status in Inkscape: A Vector Drawing Tool:
>  Confirmed
> Status in The OpenOffice.org Suite:
>  Confirmed
> Status in Tomboy:
>  New
> Status in Webkit Direct Port:
>  Fix Released
> Status in X.Org X server:
>  Invalid
> Status in Xournal:
>  New
> Status in XUL + XPCOM application runner:
>  Fix Released
> Status in Ubuntu:
>  Confirmed
>
> Bug description:
>  ===+++ _____________________ ! ALL USERS ! _____________________ +++===
>  ===+++ READ THIS BEFORE MAKING A COMMENT OR MODIFICATION +++===
>
>  IMPORTANT 1: Please see the WORKAROUND a few lines below.
>
>  IMPORTANT 2: Please don't post any "me too message"; use the "Does
>  this bug affect you?" feature you can find a bit above this bug
>  description on launchpad.
>
>  IMPORTANT 3: Do not post anything if you haven't read all comments to
>  verify that your point hasn't been made. If you feel tempted to stop
>  reading because there are too many messages, that is a strong
>  indicator that you shouldn't add even more comments. Developers have a
>  tough time to find anything if you post redundant stuff. So pl...

Read more...

Martin Lindhe (martinlindhe) wrote :

skabbedabbeda wrote 2012-01-26 14:01:
>
> My advice is to buy a Mac. I know they aren't cheap, but I did so and it
> works great. It's just absolutely gorgeous. Everything just works as
> it's supposed to.
>
> Just get rid of Linux completely.

This is a bug report please keep discussion to the bug itself.

A bug resolution is NOT to switch OS. You, of course are free to do
whatever you want.
Please keep your opinions to your personal blog or elsewhere.

/m

Eric B (eric-broszeit) wrote :

For the most part, this has been fixed. Only a few applications are still
listed, and I would not be surprised if they are fixed as well. I don't use
them to check.
No reason to get upset and spend a grand or more on a certain expensive
hardwares and OSes.
On Jan 26, 2012 8:46 AM, "Martin Lindhe" <email address hidden> wrote:

> skabbedabbeda wrote 2012-01-26 14:01:
> >
> > My advice is to buy a Mac. I know they aren't cheap, but I did so and it
> > works great. It's just absolutely gorgeous. Everything just works as
> > it's supposed to.
> >
> > Just get rid of Linux completely.
>
> This is a bug report please keep discussion to the bug itself.
>
> A bug resolution is NOT to switch OS. You, of course are free to do
> whatever you want.
> Please keep your opinions to your personal blog or elsewhere.
>
> /m
>
> --
> You received this bug notification because you are subscribed to a
> duplicate bug report (264805).
> https://bugs.launchpad.net/bugs/11334
>
> Title:
> MASTER Copy-Paste doesn't work if the source is closed before the
> paste
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/abiword/+bug/11334/+subscriptions
>

ScislaC (scislac) wrote :

"Install Windows or buy a Mac (or try to install Mac OS X on a regular PC). That's the only solution."

skabbedabbeda: Or one could install a clipboard manager... your "only" solution isn't really the only solution. I'm thankful you don't work high up in government with your jumping to "the only solution".

Dont feed the troll, please.

skabbedabbeda (skabtrebge) wrote :

3esmit (3esmit) wrote on 2012-01-26: #271
"We like linux, we believe in an open source future, where open source
is the best. We want all to be perfect, we dont want Mac."

I like beautiful girls. I believe in an open future, where open relationships are the best and I can have sex with every girl I see, without her boyfriend wanting to shoot me.

What do my perfect future and your perfect future have in common? They're both never going to happen. Open source has no future and open source will never be the best.

Eric B (eric-broszeit) wrote on 2012-01-26: #273
"For the most part, this has been fixed. Only a few applications are still
listed, and I would not be surprised if they are fixed as well. I don't use
them to check."

No, only a few applications actually do work. Most application don't work and will never work. Do you now how many applications are available in Ubuntu Software Centre? Install all of them, every single application and start testing all of them. Then there are applications which aren't even available in Ubuntu Software Centre. Start testing those applications too. A clipboard should work for EVERY application, not just a part of the applications which are installed by default.

That's why it shouldn't be fixed on a per-app basis, but it should be fixed in the core. That's how it works in other operating systems and that's how it belongs to work. In Mac OS X and Windows you can install every application you want and it doesn't matter where the application comes from, it just works, without the developer of the application having to think about implementing a clipboard. That's how it should work!

You can expect from all developers to implement a clipboard. That's why only a few application for Linux have the clipboard implemented. Just search for replies from a person called pyrates in this bug report. He knows what he's talking about. He's one the few who knows how it should be implemented and who's able to explain why the current implementation is so bad and completely wrong.

ScislaC (scislac) wrote 20 hours ago: #274
"Or one could install a clipboard manager... your "only" solution isn't really the only solution."

Clipboard managers don't work properly. They crash and don't support everything which can be copied (they only support text or text and files, but it should support everything: text, files, images, parts of an audio file, parts cut from a movie). Most of them aren't updated anymore. The developer started its project five years ago, never finished it. It's designed for a five years old Linux distribution and it haven't been updated ever since. No one is maintaing those clipboard managers, so you just can't rely on them.

An operating should have a proper working clipboard of its own. You just install the operating system and then install whatever application you like and it should just work, without the need of installing a clipboard manager, without the need to keep the source window open and without developers having to implement a clipboard in their applications. That's something you open source idiots just don't understand... correction: don't want to understand.

papukaija (papukaija) wrote :

To maintain a respectful atmosphere, please follow the code of conduct - http://www.ubuntu.com/community/conduct/ . Bug reports are handled by humans, the majority of whom are volunteers, so please bear this in mind. Thanks.

Download full text (4.4 KiB)

Hello,

I think that this is a very important comment, that should be taken in account by Linux/GNU developers to improve this wonderful Open Source System I've use at work for 5 years (five years) with no problem, after all copy-paste can be also a bad thing and I've worked happily for 5 years even if this bug seems very strange for a system that has given me much less headache than Microsoft Word. I've written two important documents longer than 30 pages with Microsoft Word and this "perfect" program that I paid with good money refused to print both after page 30, I've had to use open office for free and everything worked... I bought an external CD burner in 2000 in a Mac store for a iMac OS 8.6, it burned 1 CD then I got always errors... If you want to feed Microsoft and Mac you can, I will feed the penguin.

Best regards

> 3esmit (3esmit) wrote on 2012-01-26: #271
> "We like linux, we believe in an open source future, where open source
> is the best. We want all to be perfect, we dont want Mac."
>
> I like beautiful girls. I believe in an open future, where open
> relationships are the best and I can have sex with every girl I see,
> without her boyfriend wanting to shoot me.
>
> What do my perfect future and your perfect future have in common?
> They're both never going to happen. Open source has no future and open
> source will never be the best.
>
> Eric B (eric-broszeit) wrote on 2012-01-26: #273
> "For the most part, this has been fixed. Only a few applications are still
> listed, and I would not be surprised if they are fixed as well. I don't use
> them to check."
>
> No, only a few applications actually do work. Most application don't
> work and will never work. Do you now how many applications are available
> in Ubuntu Software Centre? Install all of them, every single application
> and start testing all of them. Then there are applications which aren't
> even available in Ubuntu Software Centre. Start testing those
> applications too. A clipboard should work for EVERY application, not
> just a part of the applications which are installed by default.
>
> That's why it shouldn't be fixed on a per-app basis, but it should be
> fixed in the core. That's how it works in other operating systems and
> that's how it belongs to work. In Mac OS X and Windows you can install
> every application you want and it doesn't matter where the application
> comes from, it just works, without the developer of the application
> having to think about implementing a clipboard. That's how it should
> work!
>
> You can expect from all developers to implement a clipboard. That's why
> only a few application for Linux have the clipboard implemented. Just
> search for replies from a person called pyrates in this bug report. He
> knows what he's talking about. He's one the few who knows how it should
> be implemented and who's able to explain why the current implementation
> is so bad and completely wrong.
>
> ScislaC (scislac) wrote 20 hours ago: #274
> "Or one could install a clipboard manager... your "only" solution isn't really the only solution."
>
> Clipboard managers don't work properly. They crash and don't support
> everything which can ...

Read more...

Changed in gnucash:
status: Confirmed → Fix Released
komputes (komputes) on 2012-03-20
tags: added: css-sponsored-p

Problem description: After copying some text, the application was exited by the user before opening another application to paste to. The content was no longer in the clipboard after closing lowriter.

Steps to reproduce:
1. Select and copy some text in LibreOffice Writer.
2. Close Writer as well as any other instances of LO.
3. Open any text editor and try to paste the content.

Expected Outcome: The text should paste and become visible.
Actual Outcome: Nothing happens & the "Paste" option in the menu may show the applications default appearance for no content, if any.

Platform (if different from the browser):
Ubuntu 12.04

Browser: Mozilla/5.0 (X11; Ubuntu; Linux i686; rv:11.0) Gecko/20100101 Firefox/11.0

Also affects kcharselect (on Ubuntu Precise, running under KDE).

I tried it on some more programs. It affected every KDE program I tried, including: kcolorchooser (copying from a text box), kwrite, konqueror, kcalc, okular.

I tried some non-KDE Qt programs, all of which were also affected: vlc, anki, qsynth, qtoctave.

This makes me suspect it's a KDE and Qt problem, rather than a problem with these specific apps. I have therefore added KDE core and Qt to the list of affected projects.

Also, GTK 2 programs: leafpad, synaptic
GTK 3: I am still seeing this with gedit, even though it's supposed to be fixed.

description: updated

Hello Jarlath, *,
I can confirm your observation with LO Version 3.6.2.2 (Build ID: da8c1e6) under Debian Testing x86 (but seem to remember to have this same behaviour observed on my PC with Debian Testing AMD64), but I am not sure, if it is a bug from LO and/or from the clipboard. I seem to remember, that it happened to me, when copying from other applications to the clipboard (say from firefox to konsole) in the past as well. So maybe it works "as expected" (by the developers, it means ... ;) ).

Just out of interest: Are you using the default WM/DE GNOME? And have you tested it with another one (like XFCE, KDE or the like)?
HTH
Thomas.

Hi Thomas,

Thanks for your reply. I can currently reproduce this on the Ubuntu
12.04 Unity desktop which I believe uses Gnome as it's backend. I
haven't tried this on any other linux environments. I did try the same
experiment with (copying from and closing) Firefox and (pasting to)
Gedit, it worked correctly in this case.

However on MacOS 10.8 (Mountain Lion) this issue is not reproducible.
The clipboard contents are preserved on exit.

By the way, were you using KDE to reproduce this?

On 09/29/2012 11:45 PM, <email address hidden> wrote:
>
> *Comment # 1 <https://bugs.freedesktop.org/show_bug.cgi?id=48783#c1>
> on bug 48783 <https://bugs.freedesktop.org/show_bug.cgi?id=48783> from
> <email address hidden> <mailto:<email address hidden>> *
> Hello Jarlath, *,
> I can confirm your observation with LO Version 3.6.2.2 (Build ID: da8c1e6)
> under Debian Testing x86 (but seem to remember to have this same behaviour
> observed on my PC with Debian Testing AMD64), but I am not sure, if it is a bug
> from LO and/or from the clipboard. I seem to remember, that it happened to me,
> when copying from other applications to the clipboard (say from firefox to
> konsole) in the past as well. So maybe it works "as expected" (by the
> developers, it means ... ;) ).
>
> Just out of interest: Are you using the default WM/DE GNOME? And have you
> tested it with another one (like XFCE, KDE or the like)?
> HTH
> Thomas.
> ------------------------------------------------------------------------
> You are receiving this mail because:
>
> * You reported the bug.
>

Bjoern - your wiki link fails for me.

The X clipboard system relies on the app owning the selection to provide the data; if you close the app - that app isn't there; so it will fail.

There are various (varyingly expensive) hacks around this out there in various desktops; that try to serialise the clipboard at various points - I guess this could be done before exit.

Problems abound: eg. select 2^36 cells in a sheet, hit copy, exit LibreOffice - what happens ? ;-> but - that's always the way with big sheets I guess.

Are you certain this is an unexpected bug ? :-)

ups, copy paste fumble:
https://wiki.ubuntu.com/ClipboardPersistence

As for unexpectedness:
https://bugs.launchpad.net/ubuntu/+source/libreoffice/+bug/983449/comments/8
so yes, I think this is expected -- esp. since more and more other apps are using the workaroud, we start to stick out. From a UX perspective it is likey better to have all apps use one of the workarounds -- or none.

Tralalalala (tralalalala) wrote :

This bug doesn't affect me anymore. I stopped using this crappy open source shit and I've bought a Mac which just works. Problem solved.

description: updated
antistress (antistress) wrote :

see also

----- Not fixed : ------
LibreOffice : https://bugs.launchpad.net/ubuntu/+source/libreoffice/+bug/983449

Hi!

I'd like to fix this bug but could someone point to me which package to work on? Atleast hint me on how to search for that package name.

Thanking you

Regards
Shashank

Changed in epiphany:
status: New → Invalid
pyrates (pyrates18) wrote :

may I ask why epiphany is now invalid for this bug? It's a web browser, but it doesn't need copy and paste working properly?

Dear Bug Submitter,

This bug has been in NEEDINFO status with no change for at least 6 months. Please provide the requested information as soon as possible and mark the bug as UNCONFIRMED. Due to regular bug tracker maintenance, if the bug is still in NEEDINFO status with no change in 30 days the QA team will close the bug as INVALID due to lack of needed information.

For more information about our NEEDINFO policy please read the wiki located here:
https://wiki.documentfoundation.org/QA/FDO/NEEDINFO

If you have already provided the requested information, please mark the bug as UNCONFIRMED so that the QA team knows that the bug is ready to be confirmed.

Thank you for helping us make LibreOffice even better for everyone!

Warm Regards,
QA Team

I'm not sure why the NEEDINFO status is set, I have answered any questions asked. Unless you want me to write the patch :)

Please let me know what I can provide. Thanks & regards.

On 24 Sep 2013, at 02:59, <email address hidden> wrote:

>
> Comment # 6 on bug 48783 from QA Administrators
> Dear Bug Submitter,
>
> This bug has been in NEEDINFO status with no change for at least 6 months.
> Please provide the requested information as soon as possible and mark the bug
> as UNCONFIRMED. Due to regular bug tracker maintenance, if the bug is still in
> NEEDINFO status with no change in 30 days the QA team will close the bug as
> INVALID due to lack of needed information.
>
> For more information about our NEEDINFO policy please read the wiki located
> here:
> https://wiki.documentfoundation.org/QA/FDO/NEEDINFO
>
> If you have already provided the requested information, please mark the bug as
> UNCONFIRMED so that the QA team knows that the bug is ready to be confirmed.
>
>
> Thank you for helping us make LibreOffice even better for everyone!
>
>
> Warm Regards,
> QA Team
>
> You are receiving this mail because:
> You reported the bug.

Marking back to NEW unless there is a non-robo discussion/discourse to address.

description: updated
Changed in df-libreoffice:
importance: Unknown → Medium
status: Unknown → Confirmed
description: updated
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers

Related questions

Remote bug watches

Bug watches keep track of this bug in other bug trackers.