On some occasions paste special stops working and its option "Edit->Paste Special" is grayed out. I wanted to copy some text from Adobe Reader. I thought it may be a fault of Adobe Reader. So I tried with some text from Firefox - the same result. I was also unable to copy from Thunderbird. This leads me to conclude that the problem is in Writer. After trying to copy also from Kate and from Writer it started working again and those selections that I could not copy from Reader and Firefox in the first place, were suddenly copyable. I can not remember the sequence of what I did exactly to return to a working state. I will keep you posted, if I find a reproducible path.
I have noticed, that when the bug appears and I open a new document, it is possible to print special in it, while in the other is not.
The Online Help says "The available [paste] options depend on the contents of the clipboard". So I suppose that LibO developers are able to give technical information on the situations where "Paste" is available (there is something in the clipboard) and "Paste special" is greyed. This would be of great help.
hi, do you still experience this bug with recent 4.1.2 LibO release?
I never manage to reproduce it. Lib0 4.1.2.3 on Win7 : difficult to reproduce without a reproducible path. Possible causes : - the pasted text is wrong in some way, - the place (or the document) it is supposed to be pasted in is wrong in some way
Created attachment 96320 [details] Files that demonstrate the issue. Attached is a writer document and a pdf that reproduces this bug, created with LibO Version: 4.2.1.1 under Windows XP. Steps to reproduce: 1. Open the .odt document and locate the insertion point (cursor) at the end of the file. 2. Open the pdf in Acrobat Reader (version 10.1.9). 3. Using the text selection tool in Acrobat Reader, highlight the bolded text "Paste Special" and copy it to the clipboard. 4. In the .odt file, try to "paste special" by pressing ctrl-shift-v. Nothing happens. 5. In the edit menu, "Paste Special" is greyed out. 6. Pressing ctrl-v pastes the formatted text. The issue is intermittent. Sometimes, paste special works fine, somtimes it does not and the symptom is unpredictable. When the problem is occurring, you can close the odt file and open it again with the existing contents still in the clipboard and then the paste-special will work.
A little off topic. I have always thought graying out an action in a user interface is a bad idea. It is better to have the option available and if it can not be performed, it should give a message why. More than once I have just sat there and wonder why this option is disabled with absolutely no clue from the application. In that case probably this bug would have been easier to fix.
I can reproduce with Version: 4.2.3.2 Build ID: 7c5c769e412afd32da4d946d2cb0c8b0674e95e0 Ubuntu 13.10. Opening the Writer doc again or a new one allows to paste special, but not if the document is already open before the paste special. Set as New - Sophie
*** Bug 34599 has been marked as a duplicate of this bug. ***
Already known since at least version 3.3.1. Set bug 34599. Best regards. JBF
Same problem occurs in Calc 5.1.4.2 on Win7/x64 trying to copy and paste text from web pages from Firefox, Chrome, or HTML email in Thunderbird. Paste and paste special vanish from the context menu, Paste-only is all that is available and it has a greyed out "No selection available" in the submenu. Hitting CTRL-V often does paste something however, sometimes the formatted text, sometimes unformatted, sometimes garbage, sometimes nothing happens. Switch to Notepad and paste and the text is pasted no problem so it is in the clipboard confirmed. Switch back to calc -> no ability to paste. Save document, exit calc, start calc, load document, right click on cell and all of the paste options are back and work again. Now go back to firefox/chrome/etc. and highlight new text and repeat the process of saving and exiting to be able to paste HTML unformatted. Reading through bugzilla it seems that people experience these problems on Writer, Calc on 5.x, 4.x and on various versions of Linux, Windows for 3-4 years now. ;o(
I usind LO Verze: 5.4.0.3 ID sestavení: 7556cbc6811c9d992f4064ab9287069087d7f62c Vlákna CPU: 8; OS: Linux 4.10; Vykreslování UI: výchozí; VCL: gtk2; Národní prostředí: cs-CZ (cs_CZ.UTF-8); Calc: group It happens to me the same thing sometimes. The solution is only turn off LO and turn on again LibreOffice. Happen to me from page etc. http://lingorado.com/ipa/ from Firefox, Chrome, Opera ...
Bug still exists in most recent 6.0 beta1, Fedora 27 x64. It is hard to find a pattern how to reliably reproduce, but it happens randomly in most cases. As discussed above, a workaround is to save all your work, close all the libreoffice windows and reopen your work.
*** Bug 35243 has been marked as a duplicate of this bug. ***
I'm not sure, if I have the same problem or if it's another one, that has "opened" in 6.1. I can't use CTRL-Shift-V from an external program, but CTRL-SHIFT-ALT-V is working and if I use CTRL-Shift-V inside LO, then it offers me the dialog how to insert the text. 6.1.0.2 with Win 10.
*** Bug 113220 has been marked as a duplicate of this bug. ***
*** Bug 106142 has been marked as a duplicate of this bug. ***
Sometimes when paste is not available, I use workaroud: extension "Paste from Web". Seems like it's not available (anymore?). But version 1.4.2 still works.
*** Bug 98542 has been marked as a duplicate of this bug. ***
*** Bug 130429 has been marked as a duplicate of this bug. ***
*** Bug 132672 has been marked as a duplicate of this bug. ***
Bug 57147, bug 65606, bug 116983 look similar: "Paste is sometimes deactivated in toolbar and context menu and Paste Special CTRL+SHIFT+V isn't working, even though text is copied to clipboard and CTRL+V functioning." Bug is surely in Windows, but some reports here are also for Linux. I can easily reproduce in LO 6.3 in Windows, with copying from PDF or web page, so steps are rather reliable, but not so in master 7.1+. I was hoping that this was resolved, but other user reproduced again. Normally we duplicate and merge bug reports but we have 19 reports and 31 CCed users (plus those in duplicated reports), it would be a lot of messages. It's of highest importance, even not of severity, to resolve these.
The frustrating part of this bug is it's not an "every time" bug. It will work as it should for several "copy - paste special" iterations, then fail for the next. The curious part of teh bug, is the data is always there for the paste using the keyboard shortcuts Ctrl-shift-alt-V, even when teh LO gui fails.
*** Bug 133938 has been marked as a duplicate of this bug. ***
it looks as if copy and paste is a very difficult task? there are 42++ bug reports about it, since 9 years, affecting calc, writer, libreoffice, most resolved as 'duplicate' of similar reports, none of the 'not avail' or 'wrong content' solved yet, actually 7+ of those are kept as 'new', (and that as calc doesn't even try to paste complete content to different versions of calc or other spreadsheets but reduces it to text, numbers and formatting?) looks 'a little weak' and is frustrating for users, these errors have sporadic occurence, thus coders can say 'no reproducibility, no work on it', but that's another special weakness of libreoffice, in real world bugs are bugs, regardless if reproducible, if ... a car crashes regarding brake or computer failure that's to be addressed even if 200.000 identical cars didn't (yet), in my opinion it would make sense to solve the problem before bugzilla collapses to a black hole under the influence of the reports gravity ... ok, there is some time till that point, or before the management of bugs and duplicates ties up so much manpower that Libreoffice as a project comes to a standstill, this point is not far away, i'm not sure if in the future or already in the past ...
I hope this is resolved in 7.1+, which is a long way to go before release. User that reproduced again did do in special case. We don't know where was change, so called reverse bibisect was inconclusive. There's a possibility that change was in the bug that was backported to 6.4.5. We will know if we all use it and test it, even it's soon available.
besides the fact that I find hiding c#24 wrong and frustrating... (@Timur: wrote you in private) i have tried around (diligently), and with the version below i haven't yet been able to produce / provoke / reproduce any of the copy/paste bugs (which was! possible with prior versions, not everytime but in short time with most distinct descriptions), e.g. the steps from c#5 have now always worked correctly in about 20 attempts, to confirm the hope for progress, tests by other users would be welcome, Version: 7.1.0.0.alpha0+ (x64) Build ID: 006c65bbd472cb1d7d44e095714e28190b76be0d CPU threads: 8; OS: Windows 6.1 Service Pack 1 Build 7601; UI render: Skia/Raster; VCL: win Locale: de-DE (de_DE); UI: en-US Calc: CL Adobe Acrobat Reader DC, Continuous Release | Version 2020.009.20067
(In reply to b. from comment #26) ... > with the version below i haven't yet been able to produce / provoke / reproduce > any of the copy/paste bugs ... correction: as sad and frustrating as it is ... this reproducer: https://bugs.documentfoundation.org/show_bug.cgi?id=116983#c55 from tdf#116983 still fails with below version ... :-( Version: 7.1.0.0.alpha0+ (x64) Build ID: 0d45380c99c7200075d01860a2315d0ddb450f1c CPU threads: 8; OS: Windows 6.1 Service Pack 1 Build 7601; UI render: Skia/Raster; VCL: win Locale: de-DE (de_DE); UI: en-US Calc: (i know that it isn't exactly this bug, that is 'right-click-paste', this is 'paste-special unavail', but wanted to correct my 'no-repro' comment, and - assume - (sorry @Eike) all those copy/paste nastinesses are just flavours of one central weakness)
I've been encountering this issue for over a year. Currently using version 7.0.0.3 x64 on Windows 7 64-bit. I encounter this often when copying numbers from my monthly financial statements in PDF format using Foxit Reader, and attempting to Paste Special - Unformatted Text. Most of the time, shift-ins will work, and then I have to "Clear Direct Formatting". But sometimes, maybe 10% of the time, even shift-ins won't work. But if I open an empty file in a separate text editor, shift-ins *will* work. I just took some time to see if I could find a pattern in line with what others are experiencing. I cannot. Doesn't take me long to experience the problem jumping between Foxit Reader and LO Calc. Right now, any kind of paste, including shift-ins, is not working, but works in my separate text editor. I tried LO Writer as well, and no paste action is working there either.
Here is an easy way to reproduce these kinds of bugs. There are other bugs that may be dupes such as bug 116983 and bug 139084. The following steps reproduce in 7.1.0.2. Not limited to Writer. Not limited to "rich" formatted sources as simple Notepad can be used to be reproduce. 1. Open Writer (or Calc) and Windows Notepad. Position the two windows so you can see them both onscreen. 2. Type the word "test" in Notepad and select it. 3. Press Ctrl+C in Notepad. 4. Notice that the Paste toolbar button in Writer (or Calc) becomes enabled. 5. Repeat pressing Ctrl+C in Notepad several times with a 1 second delay between each press while observing Writer (or Calc) toolbar. 6. A large percentage of the time the Paste button becomes disabled. This is incorrect because the clipboard does contain the data. Usually Ctrl+V works correctly to paste the data even though the toolbar button does not indicate that paste is possible. Unfortunately, even this workaround fails often enough to be problematic. Toggling the Windows 10 clipboard manager (Settings > Clipboard > Clipboard history) does not help.
@jasonkres: super! nice reproducer, now it should be possible that a dev gets a handle on it ... :-) repro with 7.2.0.0.a0+ and 6.1.6.3 under win7x64
jasonkres commented on multiple bugs with the same comment, which is of no value here, because this bug is for Paste special. I'll remove.
hello @Timur, please be considerate when you hide comments as 'no value', it 'does' something to the people who made an effort to write these comments and who want to contribute to a good project with good will, it 'dupes' them, and this is not only generally questionable but - most likely - in this particular case completely 'wrong world', most likely @jasonkres has given in #116983 !THE! crucial hint with which then there and in #136175 the bugs became solved and most likely various other copy/paste bugs too, maybe even all ... if one wants to criticize something then less the individual endeavored one who'd put the information which is important! in a confusing system everywhere there where it fits, but rather 'the system' what: 1. has such a tattered structure that the individual would have to graduate long studies first in order not to do something wrong again and again, and 2. push-pulled this / theese far more than 60 bugs about copy/paste around for almost 20 years with diligent management of duplicates and annoying 'strangers' unresolved back and forth, a project like LibreOffice needs some fresh air and different ways of thinking from time to time, and you won't get that if you first force all newcomers to think and function exactly like the 'old hands', or to quit in frustration, that's how you get what we have right now, too few programmers, too little quality, too little progress, frustrated users, annoyed supporters, bugs that have been rotting for so long that new life is born in them, imagine that you would have annoyed @jasonkres with your action so much that he would not have written comment https://bugs.documentfoundation.org/show_bug.cgi?id=116983#c81 ... we could have pushed the problem around for another 20 years without solving it ... which dev comes up with the idea to look up why an action fails only sometimes or to read up at Micro$soft or to build in retries for a fail ... so please think 'how would I feel if I made a small mistake and publicly be reprimanded ... 'in future before deletions the modern way to deal with small errors that do not hinder further work is: ignore, any attempt to clarify costs time and nerves, and degenerates into intemperate discussions because if you take everything very strictly, you will always find people who also take it strictly, just a little bit different ... and for such a things then e.g. in religious wars thousands of people were killed ... tolerance, ignore, concentrate on the good thing itself! ...
Could affected user install LibreOffice nightly build and see if the problem persists using that build: https://dev-builds.libreoffice.org/daily/master There were some fixes done around copy / pasting a few days ago and it is unclear, if the fixes also touch on the specfic problem reported here.
changing subject as bug wasn't found on searches for copy, setting WFM as it's most likely resolved with the patches for e.g. tdf#136175, OP is exactly the behaviour solved there, feel free to reopen if still problems ...
(In reply to b. from comment #32) > so please think 'how would I feel if I made a small mistake and publicly be > reprimanded ... 'in future before deletions Please do not do that, ever. Bug tracker is a tool. It is used for a specific job. Anything anyone writes to the tracker *should* be targeted to a single goal: discover, and then fix, a problem. And not to give anyone some warm feeling like "see how cool I am, made a contribution to this project!". If whoever is *offended* by others doing the *right* job - making the bug as useful as possible, including hiding unrelated stuff - they have *wrong* attitude, and *wrong* expectations. Marking a comment like that is not intended to "offend", but to improve the ticket; taking that personally, as "being reprimanded", is just wrong. As well as it's always OK to publicly discuss and disagree with *ideas*; but any attempt to make the disagreement with other's ideas to look as a bad attitude to the opponent *personality* is *wrong*. (BTW, I'm sure that jasonkres has correct expectations and attitude; the comment that I answer to is created by another person, who actually does a lot to make many reports as *useless* as possible.) Another example: when a user e.g. files a bug, and gets *offended* when the bug is closed as NOTABUG, the user is *wrong*. When that user instead tries to find a confusion that could happen (when they believe there was such a confusion), maybe because of poor wording of original description, and politely tries to rectify the situation, they do the correct thing. So - while of course here was a *questionable* decision marking a comment as "no-value", I ask people to *not* try to take others' *feelings* into account when doing such things, only the *correctness* of the action (which IMO was incorrect in case of comment 29, and that doesn't mean there is a need to "punish" anyone - just use clean argumentation to clarify why did it actually bear a potential value in this specific case).