Clipboard contents are lost when window is closed

[Siegfried Gevatter]

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 recent clipboard specification from FreeDesktop.
http://www.freedesktop.org/wiki/ClipboardManager

Actual Status :

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

Pidgin : Fixed
Inkscape : Fixed
Gedit : Fixed
Most Gnome apps, Fixed

[Adam Guthrie (ispiked)]

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

[Thomas Winwood (jormundgand)]

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

[Bugzilla-tecnocode (bugzilla-tecnocode)]

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

[Bzbarsky (bzbarsky)]

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?

[Thomas Winwood (jormundgand)]

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.

[Rimas Kudelis (rq)]

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

[Rimas Kudelis (rq)]

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

[Rimas Kudelis (rq)]

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

[Rimas Kudelis (rq)]

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

[Rimas Kudelis (rq)]

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

[Rimas Kudelis (rq)]

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

[Rimas Kudelis (rq)]

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

[Siegfried Gevatter (rainct)]

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.

[Siegfried Gevatter (rainct)]

Sorry, forgot to say I'm on Feisty (Beta).

[Sitsofe Wheeler (sitsofe)]

Thanks for your bug report.

RainCT:
Can you indicate which programs you were copying from and to? Not all programs exhibit this issue...

[Siegfried Gevatter (rainct)]

For example, when copying from Gaim (Pidgin) to Firefox.

1. Open Gaim (Pidgin) (version 2.0.0beta6) an Mozilla Firefox (version 2.0.0.3).
2. Open a conversation window from any protocol (checked with MSN and IRC personal message).
3. Write something and either submit and copy it from the conversation or copy it directly from the input box.
(4. Optional: On Firefox, try to past it somewhere, for example on the search bar. It works.)
5. Close the Gaim (Pidgin) conversation window and try to past it again. It isn't working anymore.

[Siegfried Gevatter (rainct)]

Another one: Copy from AbiWord to Firefox / Gaim (Pidgin) or gedit

1. Open AbiWord Word Processor and write something (a single word, like "hello", is enought).
2. Select and copy it.
3. Open Mozilla Firefox, gedit, or a Gaim (Pidgin) conversation window.
(4. Optional: Try to paste it into any of these. It's working.)
5. Close AbiWord Word Processor, and now try again to past it into some of these, it won't work anymore.

I tried only with these three but probably it won't paste into any other program. I also tried re-opening AbiWord after that, it isn't pasting anything there, too.

[eppy 1 (choppy121212)]

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 )

[Rimas Kudelis (rq)]

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

[Siegfried Gevatter (rainct)]

I still experience this problem, is there anything new about that?

[Kapis (capiscuas)]

Also it happens to me from KSnapshot...Copy to Clipboard...Close Ksnapshot..... try to paste in GIMP and NOTHING is pasted because the clipboard is empty after closing KSnapshot.

[Joe_Bishop (denis-cheremisov-gmail)]

I also has this bug, both on Feisty and now on Gutsy. It's definitely coming with Gajim and Firefox.

[xtknight (xt-knight)]

It still happens in Gutsy. This bug is probably years old and it should be investigated.

[Bunny13-tm (bunny13-tm)]

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.

[Angelic579 (angelic579)]

A quick search on google turned up this fix that I now use:

sudo apt-get install glipper

Then, press alt+f2 and run the program glipper.

If you want to have it run on startup, just add it to sessions.

- Adam

[mattcasters (matt-casters)]

Confirmed the problem on Gutsy / Kubuntu.
It seems like Angelic579 is on the mark. It seems a bit painful for Kubuntu to be having Klipper and Glipper run at the same time, but it does fix things for me.
The problem was critical for me since I'm using the Eclipse java development platform a lot. Eclipse uses the SWT framework that binds to GTK. GTK seems to be the library at fault here. This CTRL-C/CTRL-V problem is indescribably annoying when you are developing.

- Matt

[Dstile (dstile)]

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.

[Saivann Carignan (oxmosys)]

Unfortunately, this bug won't be fixed in GTK or something like that. There's a new clipboard manager specification which can be found here : http://www.freedesktop.org/wiki/ClipboardManager . All programs that doesn't comply with this specification will have that little bug. You can already look at gedit and inkscape and you'll see that they don't suffer of that bug. The best we should do about that issue is to spread the word.

I'll start to do this job with common ubuntu programs. You can contribute to this task by finding programs that still have this bug in their latest version ( in Hardy ) and make sure that these programs does have a bug in their upstream bug tracking system which contains sufficient informations for developers. Don't forget to give this link in reference to the new specification : http://www.freedesktop.org/wiki/ClipboardManager .

Thanks for your contribution.

[mattcasters (matt-casters)]

I stand corrected on my previous comment: the problem persists, even with glipper running. It just happens a little bit less often.

[Eldmannen+mozilla (eldmannen+mozilla)]

Please fix this.

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

[Fred (eldmannen+launchpad)]

Please, fix this!
It bothers me much.

[sv3t (tassev)]

Problem persists in Hardy. Extremely annoying!

[DanielRoesler (diafygi)]

I can confirm this bug is still on the Hardy Heron 8.04 beta LiveCD. It should be fixed before the final release of the LTS.

[xtknight (xt-knight)]

Yup, still happens to me. Especially a lot with XChat too.

[Martin Olsson (mnemo)]

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

[Bugmail-asutherland (bugmail-asutherland)]

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

[cornbread (corn13read)]

Please fix this!

[Colin Dean (colindean)]

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.

[Colin Dean (colindean)]

The clipboard bug was working fine for me in Gutsy, but it's not in Hardy.

[Rimas Kudelis (rq)]

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

[Sitsofe Wheeler (sitsofe)]

(Evolution issue is also tracked in Bug #39513 )

[cornbread (corn13read)]

This is still an issue in intrepid. Why hasn't this been fixed and why is this only medium? I think a clipboard not working properly is a BLOCKER! Especially when we are trying to gain some market share!?!

[DanielRoesler (diafygi)]

I can confirm that this bug still occurs on Intrepid beta, at least for Firefox.

[Endolith (endolith)]

I thought this was a problem with X?

"Normally, when you copy something in an X application and you close it, the content of the clipboard is lost. This is probably one of the biggest reasons why people keep saying that copy & paste in Linux "doesn't work".

Clipboard Daemon is a program that keeps the content of your X clipboard in memory, so the clipboard won' get lost even after you close the application you copied from. It's a daemon - it has no GUI. You start it and it'll run in the background and Just Work(tm)."

http://members.chello.nl/~h.lai/gnome-clipboard-daemon/

[Daniel Holbert (dholbert)]

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

[Tralalalala (tralalalala)]

True, this one is really annoying, but still isn't fixed. I'm using Glipper for some time, but this application doesn't handle pictures. I'm now going to try that Clipboard Daemon.

[Endolith (endolith)]

Parcellite fixes this, too. Glipper just crashed when I tried to use it.

[Yann Dirson (ydirson-altern)]

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

[Simon Strandman (nejsimon)]

This is still a problem in Jaunty with the latest updates as of today.

[Endolith (endolith)]

I have been using Parcellite, which fixes this, so I haven't tried gnome clipboard daemon, but if it's a simple as installing one of these programs, shouldn't they be installed by default?

[Simon Strandman (nejsimon)]

@Endolith: I agree, why not work around this problem by enabling parcellite by default until firefox etc. is fixed?

[Endolith (endolith)]

1. Something like Parcellite might be good by default, but some might complain. If gnome-clipboard-daemon also solves the problem and doesn't interfere with other clipboard apps, that should be installed by default, since it's less obtrusive.
2. I don't think it has anything to do with Firefox. Are you able to copy and paste from other apps after you've closed them? I thought that was impossible for *all* X apps.

[mati (mati-wroc)]

Starting another daemon would increase computer startup time, which is already horrible (but it's something being worked on).
That is not a proper solution, the applications should be fixed not to destroy clipboard content.

[Endolith (endolith)]

Computer startup time is of negligible importance compared to usability and data loss. Until the apps are properly fixed, we should provide a workaround by default.

[mati (mati-wroc)]

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.

[robbert (robbertvandendoorn)]

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.

[crisis13 (crisis13)]

Hello,
I have NEVER had this clipboard problem OUTSIDE UBUNTU so, IT IS AN UBUNTU BUG!

PLEASE MAKE THIS CRITICAL AFTER 2 YEARS OFF LOSING INFORMATION FROM MY CLIPBOARD

MAYBE THIS IS NOT SERIUES FOR A PROGRAMMER BUT FOR NORMAL USERS THIS IS A BIG FRUST !!!!!

Or does this neglecting means UBUNTU tries to PUSH their way off working as a new standard?????

The LAST "UPGRADES" were DOWNgrades to my 6 year old Compaq.
NVIDAI-lecagy, is NOT woking anymore
my TRUST webcam IS NOT RECOGNISED anymore
MY TRUST-SCSI connect IS NOT recognised any more
My 3GP_file's Have suddenly NO SOUND AT ALL.

THEY USED TO WORK NORMALY !!!!!

Aperently the PRIMAIRY DEPENCIES cold HARDWARE are NEGLECTED BY UBUNTU !!!!

THE POWER OFF LINUX TO BE ABLE TO WORK ON ANY COMPUTER

IF IT ALL WORKED BEFORE
WHY NOT ANYMORE

SHOULD I STEP BACK TO SUSE 7 ????

sorry if i am frusted and yelling

BUT 2 YEARS IS A LONG TIME FELLOWS !!

[linex83 (linex83)]

This clipboard problem is really annoying, I would also like to see this fixed soon.

[David Siegel (djsiegel-deactivatedaccount)]

This is a rather difficult fix, not a trivially fixable usability bug. Therefore, it is not a paper cut.

[sklp (sklp)]

Posted a possible fix to firefox: https://bugs.launchpad.net/firefox/+bug/21202/comments/50

[sklp (sklp)]

Created an attachment (id=384458)
Possible clipboard fix

[sklp (sklp)]

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

[Mkmelin+mozilla (mkmelin+mozilla)]

Richard: you need to get the patch reviewed - see https://developer.mozilla.org/en/Getting_your_patch_in_the_tree

[sklp (sklp)]

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.

[Rimas Kudelis (rq)]

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

[Stransky (stransky)]

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

[pyrates (pyrates18)]

Why not fix this in the Xorg layer? Why are we bothering to fix it in gnome? If we fix it in Xorg, then gnome and even kde will automatically get this fix. I also don't get why this is set to medium, it should be a critical bug! This bug can cause me to lose data and any bug that does that is critical to me. Second, here is an article written that explains why it needs to be fixed and why it's taken so damn long to even look at fixing it. 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....

[pyrates (pyrates18)]

Also, for previous applications who don't follow this behavior, they should not be included until they are fixed. What's so hard about checking this bug in each of those applications, and if they have it implemented, include them. If they don't have it implemented, don't include them. Put pressure on the authors of those applications that if you don't do simple fixes like this, then you don't get included.

[pyrates (pyrates18)]

One more thing, adding any kind of daemon instead of fixing it on the Xorg layer, is a bandaid solution and wastes resources because if the daemon dies, then your clipboard appears broken again. I see this bug was submitted 2 years ago and it still effects users today. What is the hold up?

[Stransky (stransky)]

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

[Mozbugz (mozbugz)]

(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".)

[Jacob Chappelle (circuitdesoleil)]

It's up to the owner of the active selection to copy it from the PRIMARY buffer to the CLIPBOARD buffer upon closing or the selection dies with the window which is closed. This is not an Ubuntu bug or an X bug just to be clear, but a lack of adherence to the X Windows protocol. Xserver negotiates networked messages between clients since Unix and Linux where built with networking in mind.

For those people who think Cntrl+c Cntrl+vis the only way to copy try highlighting some text, change windows to another text input area and click your middle mouse button (the mouse wheel) and this allows you to press 1 button rather than 4 to do the same operation. Shift+Insert does the same.

Now, just imagine there are people out there who would actually select, right click, navigate a popup window that took 3 seconds to appear, click copy, click-raise another window, right click, navigate the 3 second life sucking popup again, click paste, and then say I hate computers after taking 6 or 7 steps to do the same operation. Now multiply this tasking by 1000 and you will really start to see life wasting away. Virus scan? defrag? reg clean? ...ouch... it hurts..!

[Endolith (endolith)]

Yes, that's the reason why this has been broken for 15 years. People who think they know better than the user how they should use their own computer, and refusing to spend time fixing something that's a bug for 99% of the population, because they don't perceive it as one themselves. This has all already been discussed:

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/

[pyrates (pyrates18)]

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.

[John Vivirito (gnomefreak)]

Is there a reason you did not add all bugs to the MASTER bug? this is common practice

[John Vivirito (gnomefreak)]

Please do not change the summary of mozilla bugs without an explaining why.

[Endolith (endolith)]

Add which bugs to the master bug?

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

[John Vivirito (gnomefreak)]

summary: - MASTER Clipboard gets lost when windows is closed
+ Clipboard gets lost when windows is closed
Endolith on 2009-08-29
summary: - Clipboard gets lost when windows is closed
+ Clipboard contents are lost when window is closed

this was the master bug and we did that for a reason. all other bugs marked as dups of bug #11334 should have been marked against this one. I changed bug #11334 to be master bug now. please in future mark dups of MASTER bugs

[Endolith (endolith)]

I was unaware of that convention, and I didn't remove the word "MASTER" from the title. #11334 was earlier and already had a bunch of dupes. Move them all into this bug if you want, I'm just trying to help consolidate things.

[Stransky (stransky)]

Created an attachment (id=407846)
an updated patch

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

[Mozbugz (mozbugz)]

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

[Stransky (stransky)]

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

[Stransky (stransky)]

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

[Mozbugz (mozbugz)]

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

[Stransky (stransky)]

Created an attachment (id=411182)
v4

Should address the comments...

[Mozbugz (mozbugz)]

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

[Stransky (stransky)]

Created an attachment (id=411407)
v4+updates

[Stransky (stransky)]

is sr requested here?

[Roc-ocallahan (roc-ocallahan)]

No

[Mozbugz (mozbugz)]

(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!

[balteo (balteo)]

This bug is a serious annoyance. Any chance it will be fixed in future releases?

[Tralalalala (tralalalala)]

balteo wrote on 2009-11-10:
"This bug is a serious annoyance. Any chance it will be fixed in future releases?"

Don't expect it to be fixed before 2021.

[srgb (work-serge)]

Everybody dies @ 2012, so why bother fixing this.
Let only geeks use Linux.

[Martin Olsson (mnemo)]

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

[Daniel Holbert (dholbert)]

(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+).

[Reed Loden (reed)]

Created an attachment (id=414679)
what I landed

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

[FMaz (fmaz008)]

This bug has been marked as a duplicate of the bug #11334, called: "MASTER Copy-Paste doesn't work if the source is closed before the paste"

If this bug still affects you, please use the "This bug affect me too" option to increase the resolution priority:
https://bugs.launchpad.net/ubuntu/+bug/11334/+affectsmetoo

The full bug repport can be seen at:
https://bugs.launchpad.net/ubuntu/+bug/11334