Clipboard is erased after closing program. affects multiple programs.

[Marcos Pinto]

gnome 2.12 has clipboard management so that if you copy something from an app,
then close the app, it'll still be in the clipboard for you to paste elsewhere.
 although this works with plenty of other applications (gedit, evolution, etc),
it does not work with firefox. if you copy something from within firefox, then
close firefox and try to paste it somewhere else, the clipboard will be blank
and there'll be nothing to paste.

ii firefox 1.0.6-1ubuntu10 lightweight web browser based on Mozilla
ii nautilus 2.12.0-0ubuntu2 file manager and graphical shell for GNOME
ii firefox-gnome-support 1.0.6-1ubuntu10 Support for Gnome in
Mozilla Firefox
ii gnome-about 2.12.0-0ubuntu1 The GNOME about box
ii gnome-app-install 0+20050903 GNOME Application
Installer
ii gnome-applets 2.12.0-0ubuntu1 Various applets for
GNOME 2 panel - binary f
ii gnome-applets-data 2.12.0-0ubuntu1 Various applets for
GNOME 2 panel - data fil
ii gnome-bin 1.4.2-20 Miscellaneous
binaries used by GNOME
ii gnome-common 2.11.0-0ubuntu1 common scripts and
macros to develop with GN
ii gnome-control-center 2.12.0-0ubuntu1 utilities to
configure the GNOME desktop
ii gnome-desktop-data 2.12.0-0ubuntu1 Common files for
GNOME 2 desktop apps
ii gnome-icon-theme 2.12.0-0ubuntu1 GNOME Desktop icon theme
ii gnome-libs-data 1.4.2-20 Data for GNOME libraries
ii gnome-media 2.12.O-0ubuntu1 The GNOME Media
Utilities
ii gnome-menus 2.12.0-0ubuntu1 an implementation of
the freedesktop menu sp
ii gnome-mime-data 2.4.2-1 base MIME and
Application database for GNOME
ii gnome-panel 2.12.0-0ubuntu1 launcher and docking
facility for GNOME 2
ii gnome-panel-data 2.12.0-0ubuntu1 common files for
GNOME 2 panel
ii gnome-session 2.12.0-0ubuntu1 The GNOME 2 Session
Manager

[Siimo2005 (siimo2005)]

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)

[Adam Guthrie (ispiked)]

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

[David Farning (dfarning)]

confirmed in 1.0.7.0ubuntu20. The contents of the clipboard are available while
firefox is running but are lost when firefoex is shut down

[Adam Conrad (adconrad)]

That's because Ctrl-C in firefox copies into the X primary clipboard (the same
one you would use in other applications with hilight-to-copy and then
middle-click-to-paste), rather than into the GTK clipboard as most GTK apps do.
 While this is a behaviour I've come to be used to (I can Ctrl-C in firefox,
then middle-click into gnome-terminal), it is rather inconsistent. Of course,
it would be really nice if the GTK clipboard manager was hacked in such a way
that it managed to preserve the X primary selection as well.

[jensporup (jens-porup)]

(In reply to comment #0)
There is a related clipboard bug with firefox, namely that firefox empties the
gnome clipboard _on startup_ as well. For instance, if I get a URL link from a
friend in mutt/konsole, copy the link by double clicking it, and then open
firefox, that copy has just been lost, and I have to go back and copy it again.
Middle click also fails to paste in firefox the same was it does in regular debian.

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

[Stu Hood (stuhood)]

I also have this issue with GNOME 2.14.1 and Firefox 1.5.0.1 in Dapper. This doesn't seem like a Wishlist item, instead it seems like a Minor bug, so I'll reflect that in its Severity as well.

[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?

[LKRaider (paul-eipper)]

Confirmed on Dapper release version with Firefox 1.5.0.4 too.
Copied data vanishes when closing the application.

[Andy Bold (andy-bold)]

Extra confirmation for Dapper.

* Start Firefox
* Copy some text to clipboard
* Close Firefox
* Try to paste to another app - the copied text is gone.

I understand the difference between X and Gnome clipboards, but this sort of thing should just work.

At the very least there should be a warning similar to the one that you get with A Certain Office Package along the lines of "You will lose your clipboard contents if you do this. Are you sure you want to quit?"

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

[mon (javiermon-deactivatedaccount)]

Hi

This also happens in edgy.

I would like to point out a thing about the new copy/paste behaviour in gnome. The other day I recommended ubuntu to a collegue at work. He told me he was going to try it. Overall he said it was a nice system with some strange things... and you know what was the first thing he mentioned? This bug.

People comming to ubuntu from other operating systems expect to have a clipboard that stores data copied from an app even when it's closed. It's a common way to work, many people are used to close applications once they have finished using them... this makes the default behaviour weird...

Anyway, it's no ubuntu faults, I would blame gnome since changes something that worked to something new that doesn't work.

Thanks

[mon (javiermon-deactivatedaccount)]

Hi

There's a new package in feisty universe that could be used until this issue is fixed upstream. The package is glipper and it's a clipboard manager which integrates fine in gnome:
http://glipper.sourceforge.net/

Since this bug affects pretty much every app on the desktop not following gtk+ clipboard protocol I think it's a nice add on. It could be tweaked to have sensible settings and so on.

thanks

[Marcos Pinto (markybob)]

kmon makes a good point. is there any way to get this included in the
ubuntu_desktop meta package? i'm sure it would be useful to 99% of
ubuntu users, most of whom have no idea that such an application
exists.

[mon (javiermon-deactivatedaccount)]

Hi

I would also like to add that since installing a gnome-clipboard daemon is a common customizaton made by external scripts and is also suggested by many ubuntu guides I believe that once this package is more well known it will be more popular on post install duties.

Currently this program looks very similar to klipper (kde) and people may argue that there are many options not necessary for the ubuntu newbie, but maybe some sane defaults (like only one history of copied text, only copy when using the copy commands and so on) could make it ready for inclusion and adoption in the main desktop.

thanks

[Alexander Sack (asac)]

upstream confirmed bugs are 'In Progress' for us.

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

[Magnes (magnesus2)]

I confirm this behavior of Firefox in Feisty Fawn. Still after closing the browser the clipboard is emptied.

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

[geeknik (brian-carpenter)]

I can confirm that this behavior is still present in Ubuntu 7.10 and Firefox 2.0.0.8. Rather annoying to see the clipboard emptied after you close Firefox.

[Ceriak (ceriak)]

Confirmed on Gutsy. Really annoying.

[Doug Holton (edtechdev)]

This is a basic bug that should have a very high priority.

Anytime you copy something in Firefox, Thunderbird, any OpenOffice application, or a number of applications, the contents of the clipboard shouldn't disappear after you close the application.

So this isn't just a firefox issue. It also happens with all the OpenOffice applications and numerous others.

If glipper is a workaround that works (I don't know), then it should be installed and enabled by default in Ubuntu.

[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)]

This is not specific to Firefox, I can reproduce that bug on evolution, thunderbird, pidgin, virtualbox, gnucash, sunbird, GIMP, OpenOffice. The only one programs that I tried that doesn't have this bug was gedit. The firefox developers on the upstream bug seems to have the same opinion. This bug is still not fixed in Hardy and Gutsy, I believe that we should find to which package is really the source of this bug because it affects a lot of programs and users.

[Chris Cheney (ccheney)]

http://www.freedesktop.org/wiki/ClipboardManager

[Saivann Carignan (oxmosys)]

According to Chris Cheney comment, it seems that this bug will have to get fixed in all linux application which doesn't comply with http://www.freedesktop.org/wiki/ClipboardManager . There was no error in the package of that bug report.

[Doug Holton (edtechdev)]

Note if you use glipper as a workaround, glipper has a bug with copying and pasting charts in openoffice.
You'll need to download and compile the latest version of glipper yourself rather than use the out of
date version in Ubuntu:
https://bugs.launchpad.net/ubuntu/+bug/185624

[Jackflap (deriziotis)]

It's funny how freedesktop expect everyone to adhere to a standard that neither no other OS has implemented, and then no one adhere's to it, and thus the feature doesn't actually work like it should do because one community expects the ownus to be on everyone else, copy/pasting has become a bit of a joke.

I mean this is pretty standard stuff, the end-user, my mother, brother and sister don't care whether evolution, thunderbird, pidgin, virtualbox, gnucash, sunbird, GIMP, and OpenOffice aren't adhering to the standard, they expect copy/paste to work. I realize that it's not about the majority here, if so, Microsoft's implementaion of HTML should be officially standardized for everyone to use, but about each community to have the right to say 'I will not implement that in that way'.

However, I do feel that it is Ubuntu's responsibility to make the desktop experience seamless for the user. Until the bugs have been reported and solved in all the aforementioned applications, I feel it would be a very reasonable solution for Ubuntu to come with a clipboard manager by default, and tolerate the performance loss until things are implemented properly.

Glipper doesn't cut it to be honest. You have to manually access the clipboard history (which is one-click, admittedly ) in order to retrieve the lost contents. However, either a patch to glipper so that it compensates for this bug is needed, or another manager which does the task properly.

[Saivann Carignan (oxmosys)]

Jackflap : I agree with you that we should all work to make things "just working" and that this new standard is a bit frustrating, but all OS have their own specifications for everything. The freedesktop specifications already had some modifications in the past and all apps fixed quickly to comply. These standards modifications does not happen often but apps must follow these specifications in order to work correctly. The standard must exist in the sense that if it would not exist, no apps would be able to use clipboard at all. If we expect clipboard to exist in Linux, there must be a respected standard like in any other OS. I think that it's pretty faster to fix this little problem in all apps than integrating a special clipboard manager but I might be wrong.

[Alexander Sack (asac)]

On Wed, Jan 16, 2008 at 11:11:42PM -0000, Saïvann Carignan wrote:
> This is not specific to Firefox, I can reproduce that bug on evolution,
> thunderbird, pidgin, virtualbox, gnucash, sunbird, GIMP, OpenOffice. The
> only one programs that I tried that doesn't have this bug was gedit. The
> firefox developers on the upstream bug seems to have the same opinion.
> This bug is still not fixed in Hardy and Gutsy, I believe that we should
> find to which package is really the source of this bug because it
> affects a lot of programs and users.
>

This won't be fixed for firefox 2 anymore. xulrunner-1.9 is now the
place to track this for mozillas.

 affects ubuntu/firefox
 status wontfix
 affects ubuntu/xulrunner-1.9
 status confirmed

 - Alexander

[Eldmannen+mozilla (eldmannen+mozilla)]

Please fix this.

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

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

[Martin Olsson (mnemo)]

I just installed the pre-relase Hardy and I ran into this bug. I run into this bug at least once a week and it annoys me every time.

[Martin Olsson (mnemo)]

Adding myself as subscriber.

[DarkMageZ (darkmagez)]

This bug has been open since pre-release dapper. We've had edgy & feisty & gutsy since then, we are now about to have yet another LTS release...
These types of issues should never survive a single release cycle, let alone 2 LTS's! Since upstream does not care about linux, I'm calling for either the mozilla-bugs team to quit passing the buck to upstream or the removal of Firefox & Xulrunner from Ubuntu.

Assigning Mozilla Bugs to the xulrunner-1.9 component.

[Bugmail-asutherland (bugmail-asutherland)]

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

[Johan (nuffsed)]

This is still present in the "released" version of Hardy. Just experienced the bug.

[MankyGitt (dnadruff)]

more that the clipboard being cleared, I am finding that if I select and copy text from a page in firefox and paste it to another app: Gedit, Lotus Notes 8, OpenOfficeOrg Word Processor, the text values are corrupted. I get replacement characters:
examples ŸŸŸŸ (copying the URL address from Firefox, to paste here - again, in firefox)
or Ÿ钀 (copying page text and pasting here in firefox)

I am running ubuntu 7.10, with standard current patched inclusions, plus eclipse, Lotus Notes 8, and VirtualBox 1.5.6 PUEL and CLAMAV
I have also observed this bug with other applications, but am unclear as to whether I'd already attempted to run firefox in that session.. need to test this more clearly.

[MankyGitt (dnadruff)]

Further information: It appears that active VMs in VirtualBox can contribute to this bug: http://www.virtualbox.org/ticket/611

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

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

[Doug Holton (edtechdev)]

Glipper is actually not a fix anymore, unlike what I posted earlier. It doesn't work, and glipper has its own set of bugs (you can't copy & paste images or charts in openoffice for example):
https://bugs.launchpad.net/ubuntu/+source/glipper/+bug/104432
https://bugs.launchpad.net/ubuntu/+source/glipper/+bug/185624

So basically copy & paste between applications is broken still in Ubuntu Hardy with no current workaround.

[Bob Radu (bobradu)]

Confirmed (again) with Firefox 3.05b on Hardy (GNOME 2.22.2)

[Magnes (magnesus2)]

It's taking time for Mozilla to fix this. Maybe it should be fixed by Ubuntu team and then send to Mozilla? It's important bug.

[Daniel Holbert (dholbert)]

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

[Tralalalala (tralalalala)]

This is a really annoying bug.

[Alexander Sack (asac)]

On Thu, Nov 06, 2008 at 09:19:41PM -0000, Magnes wrote:
> It's taking time for Mozilla to fix this. Maybe it should be fixed by
> Ubuntu team and then send to Mozilla? It's important bug.
>

I think its not understood what is really wanted ... and then how to
do that in a toolkit unspecific fashion (e.g. on low X level).

 - Alexander

[markor (markoresko)]

I think I am not experiencing this bug.
I use Xubuntu Hardy/8.04.1 amd64 with current Firefox 3.0.5.
I currently run Glipper (1.0-1ubuntu1) with XfApplet(0.1.0-3ubuntu2) inside Xfce panel.

When I copy text in Firefox and then close firefox I can paste text.
It is also listed in the Glipper Clipboard list. I am not sure, maybe this bug is fixed for Firefox?
Or I am not good at reproducing it/don`t understand bug report?

[Arthur (moz-liebesgedichte)]

@markor: Using Glipper is a workaround. It's Glipper which keeps the content in the clipboard.

[John Vivirito (gnomefreak)]

On 12/22/2008 10:35 AM, Arthur wrote:
> @markor: Using Glipper is a workaround. It's Glipper which keeps the
> content in the clipboard.
>
I'm having issues reproducing this bug. Can you please list steps to
reproce, or is it just copy/paste info from firefox?

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

@markor:
Like Arthur said: "Using Glipper is a workaround." Glipper is a clipboard manager which keeps a list of previous clipboard items. When you copy something Glipper saves the copied text into a file which is located in a hidden directory within your homedirectory. This file is just a text file, so Glipper doesn't work with images.

To test this, do the following:
- Start Firefox;
- Click with the right mouse button on an image and choose to copy this image;
- Keep Firefox open and now start The GIMP;
- Click on "Acquire" and choose "Paste as New";
- The image was on the clipboard, so it could be pasted as a new file.

Now do the following:
- Close The GIMP and go back to Firefox;
- Click with the right mouse button on an image and choose to copy this image;
- Now close Firefox BEFORE you start The GIMP;
- Click on "Acquire" and choose "Paste as New";
- The image wasn't found on the clipboard, so it couldn't be pasted as a new file.

The same behavior appears with text if you don't use a clipboard manager. To test it, disable Glipper and do the following:
- Start Firefox;
- Select some text within Firefox and copy this text;
- Close Firefox and now start Gedit;
- Try to paste the text you've copied;
- The text wasn't found on the clipboard, so it couldn't be pasted into Gedit (if you click with your right mouse button, you'll see the option called "paste" is greyed out, so it isn't available anymore, because the clipboard is empty).

@John Vivirito:
Read my reply to markor for steps to reproduce this bug.

How copy/paste works in X:
http://www.jwz.org/doc/x-cut-and-paste.html

The old way of copy paste was:
- Select some text;
- Click with the middle mouse button to paste.

This still works:
- Select some text on this page;
- Go to the Comment field at the end of this page;
- Press middle mouse button.

Selecting some text is the copy process and pressing the middle mouse button is the paste process. If you close the application that holds the selected text, you can't paste it anymore.

Most people are used to the way copy/paste works in Windows. It's also implemented in Linux, but it doesn't work in the same way. In Windows you can close an application and Windows remembers the text or picture you copied.

In copy/paste still works the same as the old way of selecting and middle clicking:
- Select some text and copy it (actually it's the same as only selecting the text without copying it);
- Paste it elsewhere (actually it's the same as pressing the middle mouse button).

Instead of copying the text to the a clipboard and remembering the contents of this clipboard till some other application overwrites the contents, the process still works like the old way of selecting and middle clicking: you still have to keep the application open in order to be able to paste the text elsewhere.

I found this blog which describes how it works:
http://elliotth.blogspot.com/2008/08/desktop-linux-suckage-clipboard.html

It says:
"The way it works is that it's more like a token that gets handed round. So if you copy in Firefox and paste Rhythmbox, what happened was that at copy-time Firefox said "if anyone wants the contents of the clipboard, they should...

[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

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

[Magnes (magnesus2)]

But there is clipboard manager in Gnome which should take care of this, no? Why it's not working with Firefox (it works with some other applications).

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

[komputes (komputes)]

I can confirm that clipboard is erased after closing programs (GnuCash,Firefox, Gimp) of this behavior on the following programs. Can the bug control group members please test, confirm and mark this as a high priority bug as it is affecting multiple programs and many users.

GnuCash:
http://bugzilla.gnome.org/show_bug.cgi?id=510205

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

The Gimp:
http://bugzilla.gnome.org/show_bug.cgi?id=510230

Ubuntu bug:
https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/21202

Spec:
http://standards.freedesktop.org/clipboards-spec/clipboards-0.1.txt

May also be related:
http://bugzilla.gnome.org/show_bug.cgi?id=564165
https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/27430

[Tralalalala (tralalalala)]

"mark this as a high priority bug"

No, they don't. Bug reports of this broken copy and paste functionality are so old, but the developers just don't care. They don't care thousands of people lost data because of this bug.

I've done everything I can think of to get this bug fixed, but the progress so far is equal to zero. In the opinion of the developers this is how copy and paste works. It's just broken by design. Linux is designed to lose the contents when the application is closed and they won't fix it.

[xtknight (xt-knight)]

This is so annoying. It should quality for "One Hundred Paper Cuts".

[Fabián Rodríguez (magicfab)]

I couldn't reproduce this unless I would go in System Monitor and kill the firefox process. Firefox stayed open allowing me to use cut & paste.

[Saivann Carignan (oxmosys)]

Fabián Rodríguez : This is clearly not intended, no process should stay open only for the purpose to keep clipboard data, there is a specification for that purpose, Firefox can exit normally without deleting clipboard data if it safes clipboard in CLIPBOARD not only PRIMARY.

http://standards.freedesktop.org/clipboards-spec/clipboards-0.1.txt

[David Siegel (djsiegel-deactivatedaccount)]

This is an enormous problem, and would improve usability drastically if fixed, but it's not trivially fixable, so it's not a paper cut.

[amdlintuxos (amdlintuxos-rambler)]

this bug is really annoing me too, currently with ubuntu 9.04(gnome 2.26.1)

[Eugenia Loli-Queru (eloli)]

This is something that Ubuntu must fix. Don't they have this "100 annoyances fixed for the next version" project going on right now? THIS bug should BE one of the 100. It's just something that people easily stumble upon. So, someone go and propose it.

[Tralalalala (tralalalala)]

That's the One Hundred Paper Cuts project, but they say this bug is too complex to be a paper cut. A paper cut is a bug that's relatively easy to fix.

[Vincent Tschanz (fogia)]

http://parcellite.sourceforge.net/ can be a good alternative to glipper

[Tralalalala (tralalalala)]

It has been said many times before, but these half-baked workaround are not a fix:
https://bugs.launchpad.net/ubuntu/+bug/11334/comments/49

[sklp (sklp)]

I got tired of this problem so I tried to fix it myself. I've attached a patch to firefox 3.5-rc2 to this post. It seems to work for me, but it should be good with some testing before it possibly becomes included. If I have time I might try to fix some other apps...

[Saivann Carignan (oxmosys)]

sklp : Thanks for your work! To make sure that your work actually is reviewed by the right people and that it can get into Firefox project, can you post your patch in upstream mozilla bug report?

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

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

[sklp (sklp)]

@Saïvann: Added to upstream bugzilla as you suggested.

[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?

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

[Saivann Carignan (oxmosys)]

This bug is invalid for firefox 3.5 as it is a xulrunner bug, which therefore affect all softwares that run in top of it.

[Micah Gersten (micahg)]

At least from a Firefox perspective, this would hit xulrunner-1.9.2 and maybe be backported to xulrunner-1.9.1.

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

[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

[mercury80 (pviken)]

I do not agree that small fixes here and there is the way to go. There is something fundamentally wrong about the clipboard in linux. From what I understand this should be fixed in the core of linux, by X11 maybe... Here is an interesting read about the clipboard manager:
http://elliotth.blogspot.com/2008/08/desktop-linux-suckage-clipboard.html

[Tralalalala (tralalalala)]

@mercury80:
Yes, you know where it needs to be fixed, I know where it needs to be fixed, most of us know where it needs to be fixed, but the developers are cocky and stubborn. They really don't care about the number of duplicates and the number of comments on the original bug report and all of those duplicates. They just don't want to fix it, so it's not going to happen.

Only real solution:
Stop using these kind of amateuristic operating systems. If you've got the money, just buy a Mac. It also has Unix-roots, it's fast and stable and everything just works. There's just a clipboard that works for all applications. Mac OS X isn't created by some amateurs who try to write some code in their spare time. Apple has a lot of professional developers who're being paid and they know how which features are important and they've got the skills to develop these features.

[Kip Warner (kip)]

"Stop using these kind of amateuristic operating systems. If you've got the money, just buy a Mac. It also has Unix-roots, it's fast and stable and everything just works."

Like you, I agree a better clipboard implementation is needed. But suggesting one succumb to non-free software as an alternative is unethical. Features are important, but in enumerating them, you suggest to us that your values are limited to superficial engineering values (speed, robustness, portability, features, and so on). Many of us, while considering those important as well, have human rights preceding these things. But that you are here in the first place, suggests that you came not out of principle, but as an alternative option, another flavour, if you will, of what you'd naturally prefer. Having said that, all I can say is that you have unfortunately missed the entire point of the philosophy of free software and would do well to either broaden your mind and actually read the GNU literature (gnu.org/philosophy), or stick to the McSoftware.

On another note, there is nothing to stop you from patching Xorg yourself. If upstream does not cooperate, hear them out and listen to what they have to say. There are typically two reasons why patches are not accepted on an active project: (1) Your idea is sound, but your technical approach is lacking; (2) Philosophically, what you are trying to do is not in harmony with the project's goals, the technical approach irrelevant.

If you disagree with their (2) response, there is nothing to stop you from forking the project. Indeed, this is done more often than you think. glibc, the heart of the GNU operating system, was swapped right out under your feet in Karmic with most people being none the wiser. It was replaced with eglibc. eglibc is a fork of glibc, for philosophical reasons.

If you don't want to fork it, there is nothing to stop you from patching at the package maintainers level. Indeed, most of the official packages contain distribution level patches. You can see this in the debian/patches directory in many of the Debian / Ubuntu source packages.

Kip

[Bartolomeo Nicolotti (bart-nicolotti)]

I wrote my master science degree work with Word on 2 different operationg system in 2001, Windows xp and Mac Os 8.6. The day the twin towers went down I spend half the night to try to print it on 2 different pc and I couldn't, only the next day on another pc, and it was the last day before term deadline

Bye
> *** This bug is a duplicate of bug 11334 ***
> https://bugs.launchpad.net/bugs/11334
>
> "Stop using these kind of amateuristic operating systems. If you've got
> the money, just buy a Mac. It also has Unix-roots, it's fast and stable
> and everything just works."
>
> Like you, I agree a better clipboard implementation is needed. But
> suggesting one succumb to non-free software as an alternative is
> unethical. Features are important, but in enumerating them, you suggest
> to us that your values are limited to superficial engineering values
> (speed, robustness, portability, features, and so on). Many of us, while
> considering those important as well, have human rights preceding these
> things. But that you are here in the first place, suggests that you came
> not out of principle, but as an alternative option, another flavour, if
> you will, of what you'd naturally prefer. Having said that, all I can
> say is that you have unfortunately missed the entire point of the
> philosophy of free software and would do well to either broaden your
> mind and actually read the GNU literature (gnu.org/philosophy), or stick
> to the McSoftware.
>
> On another note, there is nothing to stop you from patching Xorg
> yourself. If upstream does not cooperate, hear them out and listen to
> what they have to say. There are typically two reasons why patches are
> not accepted on an active project: (1) Your idea is sound, but your
> technical approach is lacking; (2) Philosophically, what you are trying
> to do is not in harmony with the project's goals, the technical approach
> irrelevant.
>
> If you disagree with their (2) response, there is nothing to stop you
> from forking the project. Indeed, this is done more often than you
> think. glibc, the heart of the GNU operating system, was swapped right
> out under your feet in Karmic with most people being none the wiser. It
> was replaced with eglibc. eglibc is a fork of glibc, for philosophical
> reasons.
>
> If you don't want to fork it, there is nothing to stop you from patching
> at the package maintainers level. Indeed, most of the official packages
> contain distribution level patches. You can see this in the
> debian/patches directory in many of the Debian / Ubuntu source packages.
>
> Kip
>
> --
> Clipboard is erased after closing program. affects multiple programs.
> https://bugs.launchpad.net/bugs/21202
> You received this bug notification because you are a direct subscriber
> of a duplicate bug (via bug 11334).
>

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

[Kip Warner (kip)]

And when I was in university, I was careful to purchase a printer whose vendor (HP) cooperated with the community in providing a free driver (CUPS) that would not necessitate I waste as much time as you had. In that case, blame the vendor, not the community.

[Tralalalala (tralalalala)]

@Kip Warner:

Like I care about the software being free or non-free. I want software which WORKS! I'm a USER, not a DEVELOPER. Don't you really understand between a USER and a DEVELOPER? I'm a user and I don't care about the source code. I want my software to work and I'm never going to view the source code and I'm not going to fix bugs myself. I want to USE the operating system and it's software, not DEVELOPING it. I also don't care if I've got to pay. If I've got to pay and it works. Why not? The developers did some good works to develop something which works, so I'll reward them by paying for their software.

That's everything I'm going to say. The same discussion is going on in 11334, so there you'll find more details about how I think about this epic failure. Please, read the comments of me and pyrates (he has some really good posts in 11334) at:
https://bugs.launchpad.net/ubuntu/+bug/11334?comments=all

[Kip Warner (kip)]

Tralalalala, I get the feeling that you began typing your rebuttal before even reading my previous followup. As I mentioned already, you would do well to peruse the GNU literature. Better to keep one's mouth shut and be thought a fool than to open it and resolve all doubt.

http://www.gnu.org/philosophy

[Tralalalala (tralalalala)]

Kip Warner wrote on 2010-02-21:
"Better to keep one's mouth shut and be thought a fool than to open it and resolve all doubt."

Then why are you still talking?

[FMaz (fmaz008)]

This bug has been mark 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

[Bartolomeo Nicolotti (bart-nicolotti)]

Hey,

I wanted to ask you to help me decide which phone to choose, please see the options here http://www.kazindoor.kz/sharp.php?6c6d. Thank you!

Very truly yours, Bartolomeo Nicolotti

From: Bug 21202 [mailto:<email address hidden>]
Sent: Tuesday, August 01, 2017 9:56 AM
To: <email address hidden>
Subject: um......what?

I was a bit lax, but not overly so. Unwitting factors in my favor were a miserable cold that I had for nearly two weeks and worry over my fiance being in the hospital.

Christmas eve we ate Chinese, as is our tradition. I didn't do too bad - two dumplings, a bowl of soup, an entree I shared with my mom, and no rice.

For Christmas dinner we made salad with dried cherries and goat cheese, filet mignon (8 oz, bigger than I usually eat), roasted asperagus, roasted new potatoes, and citrus fruit salad. I had one glass of wine. Normally I would bake pie, but instead I made a lower carb option -- apple crisp.

Other than that, I stuck to my daily caloric goals and exercised even with the cold from hell, although at a somewhat lower than usual pace in deference to my poor lungs.

That said, I am going on a cruise next week. It was supposed to be my honeymoon, but since my fiance was in the hospital on what was going to be our wedding day, it's more of a pre-honeymoon now. The wedding is being rescheduled, but the cruise has been paid for and can't be canceled without penalty. Oh, well. I doubt I will go pig wild because the fiance is on a strict low fat/carb diet. Thank goodness they provide those options on the ships.

I'm going to do my level best not to go crazy. I did well on the last cruise, so I think I'll be okay this time, too.

And when I get back, my nose will be back to the weight reduction grind stone. I am so close to a bmi that is overweight rather than obese. That is my second big goal (my first was getting under 200 lbs) and I would like to achieve it soon. After that, my third and final goal will be to have a normal bmi.

Sent from Mail for Windows 10