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

Bug #11334 reported by Arandonohue on 2004-12-20
This bug affects 351 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
Wishlist
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
vim
New
Undecided
Unassigned
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 !

LimCore (limcore) on 2009-06-02
description: updated
tags: added: epicfail
Martin Albisetti (beuno) on 2009-06-03
tags: removed: epicfail
Mat Tomaszewski (mat.t.) on 2009-06-05
Changed in hundredpapercuts:
importance: Undecided → High
status: New → Confirmed
Changed in hundredpapercuts:
status: Confirmed → Invalid
Vish (vish) on 2009-08-23
tags: added: ayatana
description: updated
description: updated
Vish (vish) on 2009-08-31
affects: hundredpapercuts → null
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
Vish (vish) on 2009-11-25
Changed in hundredpapercuts:
status: New → Invalid
Endolith (endolith) on 2009-11-25
Changed in hundredpapercuts:
status: Invalid → New
Vish (vish) on 2009-11-25
Changed in hundredpapercuts:
status: New → Invalid
Micah Gersten (micahg) on 2009-11-26
Changed in null:
importance: High → Unknown
status: Invalid → Unknown
affects: null → xserver
affects: xserver → xorg-server
Changed in xorg-server:
status: Unknown → Confirmed
description: updated
Micah Gersten (micahg) on 2010-02-09
description: updated
description: updated
C de-Avillez (hggdh2) on 2010-02-09
description: updated
Vish (vish) on 2010-02-09
description: updated
LimCore (limcore) on 2010-02-09
Changed in hundredpapercuts:
status: Invalid → Confirmed
LimCore (limcore) on 2010-02-09
Changed in hundredpapercuts:
status: Confirmed → Invalid
description: updated
description: updated
Hell Pé (hellpe) on 2010-04-01
description: updated
Changed in epiphany:
status: Unknown → New
Changed in empathy:
status: Unknown → New
Changed in abiword:
status: Unknown → Confirmed
Changed in openoffice:
status: Unknown → Confirmed
Changed in empathy:
status: New → Confirmed
Changed in xulrunner:
status: Unknown → Fix Released
Changed in hundredpapercuts:
status: Invalid → Confirmed
Changed in hundredpapercuts:
status: Confirmed → Invalid
Changed in gtk:
status: Unknown → New
Changed in tomboy:
status: Unknown → New
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
241 comments hidden view all 319 comments

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
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
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
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
23 comments hidden view all 319 comments

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

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

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

Changed in xorg-server:
status: Confirmed → Invalid
Curtis Hovey (sinzui) on 2011-11-11
no longer affects: null
Changed in gnucash:
status: Confirmed → Fix Released
komputes (komputes) on 2012-03-20
tags: added: css-sponsored-p
20 comments hidden view all 319 comments

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

11 comments hidden view all 319 comments

Also affects kcharselect (on Ubuntu Precise, running under KDE).

33 comments hidden view all 319 comments

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

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

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

32 comments hidden view all 319 comments

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
33 comments hidden view all 319 comments

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

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

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

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

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

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

Soon enough xorg will be obselete.

23 comments hidden view all 319 comments

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.

8 comments hidden view all 319 comments
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?

6 comments hidden view all 319 comments

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

This is a consequence of the X11 clipboard design and not LibreOffice specific. As such, there's not much LibreOffice itself can do about this on its own.

Changed in df-libreoffice:
status: Confirmed → Won't Fix

(In reply to comment #9)
> This is a consequence of the X11 clipboard design and not LibreOffice
> specific. As such, there's not much LibreOffice itself can do about this on
> its own.

I'm not sure that "there's not much LibreOffice itself can do"... have you seen that specifications, for ways to store clipboard content after program exit?
https://wiki.ubuntu.com/ClipboardPersistence
http://freedesktop.org/wiki/ClipboardManager/

Specifications are one thing, but there needs to be also something providing the functionality. While KDE's Klipper is run by default, I'm rather sure it doesn't implement this, I have no idea about other desktops, but IIRC GNOME has never really officially included a clipboard manager, so it's a question of how many users would have it there.

But fair enough, I guess this can be kept open for when somebody will feel like implementing this.

Changed in df-libreoffice:
status: Won't Fix → Confirmed
Tralalalala (tralalalala) wrote :

In LibreOffice Bugzilla #48783, TenLeftFingers (tenleftfingers) wrote on 2012-09-30:

"However on MacOS 10.8 (Mountain Lion) this issue is not reproducible.
The clipboard contents are preserved on exit."

Of course, because OS X is a proper operating system with a clipboard that always, because of the way it's implemented in the operating system itself. It has been said many times: A clipboard should be a feature of the operating system itself and applications shouldn't have to write code to make copy/paste work. Write an application for Windows, OS X or even iOS and copy/paste just works. There's no need for the developers to implement this feature to make copy/paste work.

That's why Linux is such a useless operating system.

In LibreOffice Bugzilla #48783, L-lunak-w (l-lunak-w) wrote on 2014-04-25:

"This is a consequence of the X11 clipboard design and not LibreOffice specific. As such, there's not much LibreOffice itself can do about this on its own."

You shouldn't even do something. Just don't fix it. It's absolutely ridiculous all applications have to be "fixed" by its developers. I surrounded "fixed" by quotation marks, because of course the applications are not broken at all. It's the operating system itself that's broken and they refuse to fix their crappy operating system and expect all developers to write code to make copy/paste work on their piece of shit called Linux. I'd say they can go fuck themselves. Just spend your time on Windows and OS X. Just don't give a single shit about Linux, just like 99,5% of the world doesn't give a shit about Linux. It's a useless piece of crap that doesn't even deserve developers who spend time writing software for it. Developers should just write software for Windows and OS X and ignore that fucking piece of shit.

I click on "Post Comment" and Launchpad says:

"Error
Timeout error, please try again in a few minutes."

How surprisingly, something developed by Linux developers doesn't work. Fucking losers.

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

This is not LibreOffice’s bug.

This has to do with the whole X server architecture. Deep level stuff. An historical issue in Linux distros using X.

Citing Michael Meeks (from bug 48783):

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

See https://bugs.launchpad.net/ubuntu/+bug/11334 for boring details and funny rants.

Bjorn has stated there is a workaround for this and i think it should be implemented as other apps are also using the workaround. I dont think linux users should be penalized by X's issue with the clipboard.

Most of my reaction to this is non-technical so I'll save it for another
forum. But I'm disappointed that this is the outcome after two-years when
this was first reported. I agree with Jay Philips above that other apps are
managing this scenario for their users.

On Fri, Jun 13, 2014 at 11:05 AM, <email address hidden> wrote:

> Jay Philips <email address hidden> changed bug 48783
> <https://bugs.freedesktop.org/show_bug.cgi?id=48783>
> What Removed Added Status RESOLVED REOPENED Resolution NOTOURBUG ---
>
> *Comment # 14 <https://bugs.freedesktop.org/show_bug.cgi?id=48783#c14>
> on bug 48783 <https://bugs.freedesktop.org/show_bug.cgi?id=48783> from Jay
> Philips <email address hidden> *
>
> Bjorn has stated there is a workaround for this and i think it should be
> implemented as other apps are also using the workaround. I dont think linux
> users should be penalized by X's issue with the clipboard.
>
> ------------------------------
> You are receiving this mail because:
>
> - You reported the bug.
>
>

Changed in df-libreoffice:
importance: Medium → Wishlist

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

After reading through the links provided on this page, the ubuntu clipboard persistence page has stated that a user can solve this issue for libreoffice and all other applications by installing a clipboard manager. It recommends parcellite, but mentions alternatives for xfce (clipman), KDE (klipper) and Gnome (glipper) desktop environments. Just placing this information here for future users to find encase they file the same bug and want a solution until libreoffice solves it itself.

Setting this to NEW as i mistakenly set it to REOPENED.

7 comments hidden view all 319 comments

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

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

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

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

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

Displaying first 40 and last 40 comments. View all 319 comments or add a comment.
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.