Description: To date, only tested on Linux/64-Bit. Issue: After scraping data from another application [specifically, Firefox], an attempt to paste the same to an empty Calc tab, using the options: "Paste Special" / Unformatted Text" results in a situation where for every single successive paste , the application forgets the options previously set and defaults back to an incorrect set of values. This issue did not occur with the previous edition of LO I was running, 24.8.6.2. The data I am trying to capture originates in the form of a table of electricity consumption data [from a smart meter]. Where each row of the data looks like this: 12:00am 0.10 kWh and there are 48 rows per day [sampling every 30 minutes]. With 24.8.6.2 I was able to select "Paste Special" and then "Options" and then select the attributes I wanted the application to take, for example selecting the "Separated by" top level option. Beyond "Separated by", the dialogue box for both editions of LO has a series of radio-button selection options, for things like tab, comma, semicolon, space and other. For my data, I want to have the "space" option active. However, with 25.2.3.2, each time I return to my "work area" tab to paste the raw data ahead of formatting it, the dialogue box has returned to what I'll describe as "shipping defaults". With LO 24.8.6.2, once I had set the "paste special" dialogue options the very first time I used that edition, it remembered those settings across restarts. The process I'm using is highly repetitive and this paste special option is a critical part of my workflow. It probably sounds trivial, but having to go to the dialogue screen and accurate click the "space" option slows the whole process down massively... Is there any way you would either be willing to revert this dialogue back to "do the least surprising thing", which is remember the options I set once I have set them? I kept the earlier edition of LO installed on my machine, which means that I can revert back to it for this task... so I don't think this qualifies as an "urgent" bug... but I'd be very grateful if you could revert this paste option back to "least surprising" operation please? Is it possible that this change is related to the extra options that appear with the "Paste Special" dialogue box in 25.2.3.2? Thanks in advanced. Steps to Reproduce: 1. Launch Calc 25.2.3.2 2. Find a web page or similar source with tabulated numeric/text data 3. Attempt to paste to a workbook tab using "Paste Special" 4. Activate the option to use "space" as a separator and see the paste works as expected... 5. Go back to the web page and retrieve more data 6. Return to the "Paste Special" dialogue box and see that LO has "forgotten" that you just asked it to use "Space" as a separator when using "Paste Special" to paste data. Actual Results: Calc keeps resetting it's "Paste Special" options back to the defaults each time it is used, which is *really* annoying... Expected Results: I would expect LO Calc to remember the Paste Special dialogue options. At minimum, I would expect it to remember the options between successive uses during a single launched execution of the binary - i.e. without closing and re-starting. Ideally I would expect it to consistently reproduce the functionality of earlier 24.x editions, where it can remember the options I set across restarts. Reproducible: Always User Profile Reset: No Additional Info: [Information automatically included from LibreOffice] Locale: en-GB Module: Spreadsheet - Calc CL threaded OS: Linux (Mint) OS is 64bit: yes Build: Version: 25.2.3.2 (X86_64) / LibreOffice Community Build ID: bbb074479178df812d175f709636b368952c2ce3 CPU threads: 32; OS: Linux 6.8; UI render: default; VCL: gtk3 Locale: en-GB (en_GB.UTF-8); UI: en-GB Calc: CL threaded
There were similar problems reported on the German Ask for Windows 11. There has been a fix for bug 165744 about a similar problem. That fix will be included in version 25.8. The fix is also included in a daily build. A daily build can be installed parallel to the regular installation. It will be installed as LibreOfficeDev. You could test, whether your problem still occurs in a daily build. Daily builds are available from https://dev-builds.libreoffice.org/daily/master/current.html The settings in that dialog should be saved in the file registrymodifications.xcu in your LibreOffice user profile.
*** This bug has been marked as a duplicate of bug 165684 ***
Mm, not really duplicate to bug 165684. That one is the request to not remember a dialog setting. This one is a report that a previously remembered setting is no longer remembered.
Thanks, @Regina Henschel, I will try and pull down a daily build this weekend and re-test. Thanks also for noting that this bug is not a duplicate of 165684 - your comment with the correction is exactly right: I am asking if it would be possible to return the code back to the version where it remembers a dialogue setting provided by the user. With 24.8.6.2, whatever options I selected in the "Paste Unformatted" dialogue were preserved across multiple activations. As you note, that would have been in the file registrymodifications.xcu. However, you have now given me another clue regarding this bug, which is that I have this problem with the AppImage version of 25.2.3.2, not the "unpacked installation" version. Could that make a difference? [The reason I'm using AppImage is because I use Mint as my OS of choice, but the Mint equivalent of "LTS" releases does not update LO versions, so if I want to upgrade to something a bit newer, I simply pull down the AppImage file and add a second set of launch options to my Cinnamon Menu. This also means that I can test between versions relatively easily.
I have just re-tested in 25.2.4.3 and it looks that this issue has now been resolved. The behavior I see with the latest Stable edition has reverted to the same result seen with 24.8.6.2. I think this issue is now resolved. Can I ask someone else to please confirm so that we can close this issue? Thanks to the Devs and the Triage Team for addressing this promptly!
OK, please disregard my previous post [Comment #5]. Something *really* weird just happened. I'm running the 64-bit AppImage of 25.4.3, downloaded about an hour ago. The very first time I used "Paste Unformatted Text", everything worked as before and as I would have expected. Delighted, I came here and made the previous post. I've just returned to my processing for the day and repeated the paste process and it has not worked. It is now "not working" reliably. I am able to work-around by either using an older binary, or by changing the "Separator Options" in the "Paste Unformatted Text" dialogue box to shift it from "Detected (space)" to "Separated by" - that is all that it takes to work. But we should still be able to set it this way and have LO preserve that preference, which still appears to be broken.
I have now downloaded, installed and tested 25.2.6.2 and I can confirm that the bug remains in place. I am able to "Paste Special" ... "Unformatted Text" and then select the "separated by" option and see that the software correctly formats the paste of data in to a Calc tab. However, the next time I go to perform the task, all parameters of the "Paste Special" dialogue box revert to their default values, which breaks "The Rule of Least Surprise" (see here: http://www.catb.org/~esr/writings/taoup/html/ch01s06.html#id2878339 ) It's terrific to see a steady cadence of new point releases for LO... but I note that we've had several releases now since I first reported this defect/functionality change in June... and I don't see any sign of anyone tracking down the code or providing any feedback as to whether or not this will be fixed. May I ask about that please? Should I simply retain the last reliable, working version of LO and use that? Thank you.
I can confirm this issue affects my workflow as well. This regression significantly impacts productivity when working with repetitive data processing tasks. ### Additional confirmation details: Version: 25.8.2.2 (X86_64) Build ID: d401f2107ccab8f924a8e2df40f573aab7605b6f CPU threads: 12; OS: Windows 10 X86_64 (build 19045); UI render: Skia/Vulkan; VCL: win Locale: ru-RU (ru_RU); UI: ru-RU Calc: CL threaded ### My specific use case scenario: "I frequently insert entire rows or columns with shifting. The dialog exhibits inconsistent behavior: - The 'Shift cells' section correctly remembers my previous selection (right/down) - However, the 'Insert' section (Numbers, Text, Date/Time, All) always resets to default values, forgetting that I previously selected 'All' Previously, the entire dialog remembered all my selections, but now only partial settings are preserved."
Please DO NOT change the versions affected: you can see the field is named: "Version (earliest affected)", in order to know when the bug first apear, is not the latest version that someone tested. Thanks for understanding and retesting.
TLDR: Having the same issue mentioned here -- on Arch it's been a week-ish since I've noticed this behavior and I updated the package in Fedora 42 to 25.2.7.2 to validate if it was the OS, but it triggered the same bug (before it was working just fine). Previous version (25.2.6.2 in Fedora 42) was working. Summary: when copying data (decimal point values) in a row separated by spaces, after ctrl+shift+v > "Use text import dialog" I was automatically splitting the data so when I was touching enter it would directly parse all the values as columns. After the recent updated, the same procedure would end up overwriting the data in the clipboard with nothing, so you'd see a single row and a single column and nothing in it. The size of the column was quite small (only a letter fits inside). Touching enter would not include any new information to the spreadsheet. Tried in safe mode and the result was the same. Later, I updated it in Fedora 42 and it went from working to having the same problem. Expected behavior: to be able to see the data (processed or not) in the dialog, and apply the correct separation before merging the data in Calc.