Bug 48783 - Clipboard cleared on exit on Linux
Summary: Clipboard cleared on exit on Linux
Status: RESOLVED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
Inherited From OOo
Hardware: All Linux (All)
: medium enhancement
Assignee: Not Assigned
URL:
Whiteboard: BSA
Keywords:
: 81233 89177 (view as bug list)
Depends on:
Blocks:
 
Reported: 2012-04-16 13:39 UTC by Jarlath Reidy
Modified: 2016-10-25 19:48 UTC (History)
10 users (show)

See Also:
Crash report or crash signature:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Jarlath Reidy 2012-04-16 13:39:24 UTC
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
Comment 1 Thomas Hackert 2012-09-29 22:45:38 UTC
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.
Comment 2 Jarlath Reidy 2012-09-30 13:29:28 UTC
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, bugzilla-daemon@freedesktop.org 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 
> thackert@nexgo.de <mailto:thackert@nexgo.de> *
> 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.
>
Comment 3 Björn Michaelsen 2012-10-08 08:45:00 UTC
Confirmed by multiple affected users.

https://wiki.ubuntu.com/ClipboardManager
Comment 4 Michael Meeks 2012-10-08 09:02:44 UTC
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 ? :-)
Comment 5 Björn Michaelsen 2012-10-08 09:17:58 UTC
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.
Comment 6 QA Administrators 2013-09-24 01:59:00 UTC Comment hidden (obsolete)
Comment 7 Jarlath Reidy 2013-09-24 10:52:26 UTC
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, bugzilla-daemon@freedesktop.org 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.
Comment 8 Chris Peñalver 2013-09-26 10:25:30 UTC
Marking back to NEW unless there is a non-robo discussion/discourse to address.
Comment 9 Luboš Luňák 2014-04-25 14:20:04 UTC
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.
Comment 10 Stefano Bagnatica 2014-04-26 06:10:45 UTC
(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/
Comment 11 Luboš Luňák 2014-04-27 08:34:38 UTC
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.
Comment 12 Maxim Monastirsky 2014-06-10 09:40:02 UTC
*** Bug 79872 has been marked as a duplicate of this bug. ***
Comment 13 Adolfo Jayme Barrientos 2014-06-13 01:51:19 UTC
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.
Comment 14 Yousuf Philips (jay) (retired) 2014-06-13 10:05:53 UTC
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.
Comment 15 Jarlath Reidy 2014-06-14 19:49:49 UTC
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, <bugzilla-daemon@freedesktop.org> wrote:

>  Jay Philips <philipz85@hotmail.com> 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 <philipz85@hotmail.com> *
>
> 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.
>
>
Comment 16 Yousuf Philips (jay) (retired) 2014-07-11 22:42:11 UTC
*** Bug 81233 has been marked as a duplicate of this bug. ***
Comment 17 Yousuf Philips (jay) (retired) 2014-07-11 23:23:34 UTC
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.
Comment 18 raal 2015-02-07 18:55:56 UTC
*** Bug 89177 has been marked as a duplicate of this bug. ***
Comment 19 Jean-Baptiste Faure 2015-02-07 19:55:37 UTC
Strange thing, for me clipboard persistence is a security issue. I hope that, if workaround is someday implemented, we will have an option to disable it.

Best regards. JBF
Comment 20 Yousuf Philips (jay) (retired) 2015-02-08 02:36:47 UTC
(In reply to Jean-Baptiste Faure from comment #19)
> Strange thing, for me clipboard persistence is a security issue. I hope
> that, if workaround is someday implemented, we will have an option to
> disable it.

If you consider this a security issue, then it would be useful to file a new enhancement report so Windows and Mac users can tell libreoffice to clear the clipboard on exit. Likely it can be a checkbox in Tools > Options > Security.
Comment 21 Jean-Baptiste Faure 2015-02-21 23:03:38 UTC
(In reply to Jay Philips from comment #20)
> [...]
> If you consider this a security issue, then it would be useful to file a new
> enhancement report so Windows and Mac users can tell libreoffice to clear
> the clipboard on exit. Likely it can be a checkbox in Tools > Options >
> Security.

No time for that. You can not make people happy despite themselves. But this is not the place to discuss this.

Best regards. JBF
Comment 22 Peter Evans 2015-05-31 20:59:41 UTC
I am a new user for Bugzilla, just wanted to report this issue but I've noted this is a duplicate report.  Anyway, today I'm confirming that this "no clipboard persistence" issue still exists, using LO Version: 4.2.8.2
Build ID: 420m0(Build:2) with Lubuntu Linux 14.04.  I noted this behavior today.  Thanks for all of your good work, and best wishes for a future solution to this minor issue!
Comment 23 Cor Nouws 2016-01-21 13:48:33 UTC
I close this one
See
  http://cgit.freedesktop.org/libreoffice/core/commit/?id=f1358edf469e70df1fb044bb58cd888fea15173c

Please check in a daily build tomorrow or soon thereafter.
Comment 24 Cor Nouws 2016-01-21 14:00:08 UTC
"(14:58:56) caolan: CorNouws: only for the gtk3 vclplug, not globally under Linux, just with that one specific backend"
Comment 25 Cor Nouws 2016-01-21 14:00:24 UTC
So sorry, not all fixed
Comment 26 Caolán McNamara 2016-03-14 11:16:39 UTC
I'll call this fixed as its fixed in the default-when-available gtk3 backend and its not going to get implemented for anything else at this point
Comment 27 Yousuf Philips (jay) (retired) 2016-03-20 11:06:18 UTC
Not sure how it being fixed on gtk3 builds solves this issue when TDF distributes gtk2 builds and we have a workaround that other apps implement that we can also implement.