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
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, 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. >
Confirmed by multiple affected users. https://wiki.ubuntu.com/ClipboardManager
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.
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, 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.
Marking back to NEW unless there is a non-robo discussion/discourse to address.
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.
(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.
*** 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, <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. > >
*** 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.
*** Bug 89177 has been marked as a duplicate of this bug. ***
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
(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.
(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
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!
I close this one See http://cgit.freedesktop.org/libreoffice/core/commit/?id=f1358edf469e70df1fb044bb58cd888fea15173c Please check in a daily build tomorrow or soon thereafter.
"(14:58:56) caolan: CorNouws: only for the gtk3 vclplug, not globally under Linux, just with that one specific backend"
So sorry, not all fixed
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
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.