Description: I have a old Calc file updated monthly with 1000s of rows of personal data. About a year ago I had this problem with this file. This week I received a .xlsx file from a server. Adding text to it was not saved for reasons unknown, so I copied its content as text and numbers only into a Calc file. All cells were unwrapped, and remain unwrapped in the original file. I added several comments in red text a few days ago and discussed them days later. Today, after I entered some text into sheet "Damage Covered" at l79 it entered as wrapped text. It unwraps when requested and immediately reverts to wrapped. This action seems to have triggered an existing unwrapped cell that has been stable on several occasions of opening and closing this file to wrap itself, sheet "Damage Declined", D58. So this attached file has the same issue on two separate sheets. I did not touch the latter sheet: a cell within it wrapped itself. This issue started with an Intel MacBook Pro over a year ago. I am now using a M2 MacBook Air with macOS Sonoma 14.5 (23F79) When it happens, it then happens every time. Saving can trigger this too. I tried to reproduce it using an empty cell, but I could not reproduce this. I tried to reproduce this in the original revised file, but I could not reproduce this. Files affected n this way never recover. Several cells have spontaneously wrapped themselves in my personal files that cannot be un-wrapped. Steps to Reproduce: 1.enter a long string of characters into a cell that is not set to wrap. 2.if it wraps, try unwrapping it 3. if it does not wrap itself, then wrapping and unwrapping does not reproduce this Actual Results: FORMATTING error Expected Results: Settings to behave as expected Reproducible: Sometimes User Profile Reset: No Additional Info: User data is empty except for two pre-ticked boxes. I think this is my user profile as I cannot find anything with that title to reset. I do not have a help button in my menu bar or menu drop-down lists as instructed, nor do I know how to restart LibreOffice in safe mode.
Created attachment 194765 [details] Declined.ods has 6 sheets of financial data and text
I'm not able to reproduce Version: 24.2.4.2 (X86_64) / LibreOffice Community Build ID: 51a6219feb6075d9a4c46691dcfe0cd9c4fff3c2 CPU threads: 16; OS: Windows 10.0 Build 22631; UI render: Skia/Raster; VCL: win Locale: es-ES (es_ES); UI: en-US Calc: CL threaded Could it be in relation with 'Expand formatting' Calc option. https://help.libreoffice.org/24.2/en-US/text/shared/optionen/01060300.html?System=WIN&DbPAR=CALC&HID=modules/scalc/ui/scgeneralpage/ScGeneralPage#:~:text=Expand%20formatting,attributes%20of%20the
My bet (not really tested) is that the reason is the same as other issues with either wrap text or multi line text within a cell. Similar issues are reported with LO 24.2, whether in ODS files or when importing/exporting from/to XLS and/or XLSX. Examples: Bugs 159690, 160900, 161453. There are possibly others (and there will be more).
BTW, based on tdf#159938, the issue should be _partially_ solved with LO 24.2.2.
Thank you Ady. My reaction; Bugs 159690: Adding a manual line break, then press "Enter" key, forces a not needed automatic wrap text. Lesson: avoid line breaks for now until this is resolved. Bugs 160900, 161453 The first seems unrelated, the second maybe related. In my latest case that I submitted, I did not have a line break. With my other calc files saved as .ods or .xls I often do have line breaks. Issue remains.
Whether you see a line break or not is not what relates those other reports to your case, but rather the imposed Wrap Text property of the relevant cells. I would suggest making a copy of at least one of the files in which you see the problem, and installing the latest stable LO 24.2 version (instead of using the older LO 24.2.1). Then open the file with that new version and correct the cells (i.e. remove the Wrap Text property of the relevant cells). Save the file and reload it. Is the file saved correctly? Are the cells "unwrapped"? Please report back.
Dear John, 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 INSUFFICIENTDATA due to lack of needed information. For more information about our NEEDINFO policy please read the wiki located here: https://wiki.documentfoundation.org/QA/Bugzilla/Fields/Status/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 MassPing-NeedInfo-Ping
Sorry for the delay due to excessive domestic family needs. After update to macOS to 15.1.1 and LibreOffice, I cannot repeat the issue with LibreOffice 24.8.3.2 or 24.2.1.2! Two months ago I had the same issue using LibreOffice 24.2.1.2 (I reverted to that due to an inter-sheet linking issue with the updated version in use at that time. This I did not report, but I may do so if it continues with 24.8.3.2, as I update my file once monthly). I spent 3 hours today on a copy to create a test sheet for you by removing all sensitive data from one sheet and deleting the adjoining 12 sheets of sensitive data in this one test file. Before submitting the test file I performed the actions that would normally cause my issue, but they did not re-occur with both the test file and the original file with both the above versions of LibreOffice. I don't understand this as it has been occurring for about three years. The sheet I chose is one I know where the errant cells are: it is updated around September each year.
I have searched for and failed to locate the file I first mentioned: "I entered some text into sheet "Damage Covered" at l79 it entered as wrapped text. It unwraps when requested and immediately reverts to wrapped." As I can't find a file with an entry at row 79, I assume this was a first draft that has been superseded. I suggest this be closed until such time that the issue re-occurs.