Copy text from
GNOME Terminal Server or Konsole (for KDE)
Try to paste into LibreOffice Writer
in maybe 10% of the cases, paset unformatted text is unavailable
- control+shift+V does nothing
- menu LibreOffice - Edit - Paste Special… is gray
control+shift+V or Edit - Paste Special… - Unformatted text to paste un-styled text
for the same copy, abiword clipboard works as expected
This bug has been present for many years.
Verified for KDE/X 16.04 and GNOME/Wayland 15.10/16.04
dpkg --status libreoffice | egrep "^(V|Pa)"
You don't have an example text that shows the problem every time?
The bug does not happen every time.
If anyone would regularly use GNOME or KDE on X or Wayland to copy from terminal window or browser to LibreOffice, they will find it within a day.
This has been present for many years, and I have seen people blame X or chromimum-browser.
By using abiword, that also acts differently whether there is styled or unstyled text on the clipboard, I could confirm that the bug is in LibreOffice Writer.
The code that fails is to determine what is on the X clipboard. For styled text, LibreOffice occasionally behave like the clipboard holds unstyled text.
To try out this difference, paste a text selected from a Web page as opposed to from an unstyled source like the gEdit or Kate text editors.
It does not appear that the bug depends on the particular text content, since copying from the terminal window produces different texts but in an identical styling environment.
The first impact is inconvenience, because a habitual control+shift+V occasionally does not work
The second is that when this bug happens, text cannot be pasted without styling.
The user is therefore forced to paste the text into an unstyled source like gEdit or Kate, copy it from there, and then do a regular paste in LibreOffice.
I believe this bug affects all Linux users of LibreOffice
Actually, it seems to be that the code that detects clipboard format is not run when LibreOffice is again brought to front
- copy a text from gEdit/Kate
- Examine Edit menu: Paste special gray
- copy text from styled source
- Examine Edit menu: Paste special gray BUG!!
open a new Libreoffice window using control+N
- Examine Edit menu: Paste special now available
(In reply to yolo from comment #6)
> Actually, it seems to be that the code that detects clipboard format is not
> run when LibreOffice is again brought to front
> - copy a text from gEdit/Kate
> - Examine Edit menu: Paste special gray
> - copy text from styled source
> - Examine Edit menu: Paste special gray BUG!!
> open a new Libreoffice window using control+N
> - Examine Edit menu: Paste special now available
No problem here.
Arch Linux 64-bit, KDE Plasma 5
Build ID: 1dbdc947fcc9d843764731e6dae7ce60082576e0
CPU Threads: 8; OS Version: Linux 4.5; UI Render: default;
Locale: fi-FI (fi_FI.UTF-8)
Built on May 14th 2016
I'm experiencing this very exact problem in Calc on Windows 7/x64 using version 188.8.131.52 of LibreOffice. It is 100% reproduceable for me.
I have a spreadsheet open, I go to a web page in Firefox 47.0.1 or Thunderbird HTML email or any other HTML or RTF source and highlight a few words or a sentence or more, switch back to LibreOffice Calc and right click to paste-special and remove the formatting. When I do this sometimes it just works no problem, other times all of the paste options are either missing entirely from the right click context menu or they're greyed out. If it is bugging out and anything shows it is "Paste Only" and it says greyed out in the submenu off of that "<No selection possible>". If I then save my document, exit Calc completely, reopen calc and reload the same document - without modifying the clipboard, then right click into the same cell, magically all of the paste options show up again and it works.
At that point I might be able to copy and paste a few more things from Firefox/Thunderbird etc. and have it work, or it will do it again after a few more pastes completely at random. Save+exit+restart+reload and right click fixes it every time.
Like someone mentioned above, I've found via testing that if I paste the text into Notepad on Windows first, then re-highlight it in Notepad and try to right-click paste it into Calc it will work fine.
Additionally, when the problem described occurs and all of the paste options are greyed out and/or non-functional on the context menu and top pulldown menus - CTRL-V still works even though Paste is greyed out. But by "works" I mean it pastes rich text into the document and it always has randomly different results that seem to have no pattern.
In all cases, saving and exiting and reloading solves all of the cut and paste problems for at least one single paste for sure, and maybe 2-3 if I get lucky.
New Get-Around for this truly present bug that had no activity for 2 months:
When Paste Special… is incorrectly gray preventing pasting of unstyled text
Open a dialog, say File - Open… and close the dialog by clicking Cancel
tada: Paste Special… is now available!
A similar problem exists with Find control+f
This bug affects multiple poeple
Similar to bug 102311
In regards to the "No problem here." comment above
This does not happen every time. As I noted to me it happens in approximately 10% of my paste attempts.
I experience this bug with LO Writer Version: 184.108.40.206, Build ID: 1:5.2.3~rc1-4 on Debian Testing, KDE environment.
I experience the same problem. Maybe even "worse". I have a text in gedit in order to be able to paste it in Impress (but I think the problem arises also in Calc and Writer). Usually I can do paste special, but some times, for no reason, it is disabled (grayed). Btw, If I paste the text from gedit with the regular paste, then I have another behaviour (for ex, in a bulleted line, it takes out the bullet). I have:
Build ID: 1:5.2.3~rc2-0ubuntu1~trusty1
Linux 4.4.0-53-generic #74~14.04.1-Ubuntu SMP Fri Dec 2 03:43:31 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux
All the best.
Sorry, I forgot to mention that the trick:
Open a dialog, say File - Open… and close the dialog by clicking Cancel
did not work for me.
** Please read this message in its entirety before responding **
To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year.
There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present.
If you have time, please do the following:
Test to see if the bug is still present with the latest version of LibreOffice from https://www.libreoffice.org/download/
If the bug is present, please leave a comment that includes the information from Help - About LibreOffice.
If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a comment that includes the information from Help - About LibreOffice.
Please DO NOT
Update the version field
Reply via email (please reply directly on the bug tracker)
Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not
appropriate in this case)
If you want to do more to help you can test to see if your issue is a REGRESSION. To do so:
1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) from http://downloadarchive.documentfoundation.org/libreoffice/old/
2. Test your bug
3. Leave a comment with your results.
4a. If the bug was present with 3.3 - set version to 'inherited from OOo';
4b. If the bug was not present in 3.3 - add 'regression' to keyword
Feel free to come ask questions or to say hello in our QA chat: https://kiwiirc.com/nextclient/irc.freenode.net/#libreoffice-qa
Thank you for helping us make LibreOffice even better for everyone!
This (Linux originated) bug has no steps.
Seems the same as (marked Windows) Bug 116983 that (hopefully) has steps.
Now that related, they may remain open until we have some change.
*** Bug 112227 has been marked as a duplicate of this bug. ***