Description: This bug has never happened in Calc ≤ 7.6.4 and is so annoying. Whenever I open an ods file or create a new one that has some text that is longer than the cell size, there comes a point when Calc starts to behave as if the option “Wrap text automatically” is set true for each cell I move through. As I browse the file, rows start expanding at their own initiative when you move out of one cell of the row. As each cell is changed at once, this also fills the undo list with a lot of “Attributes” actions. I don’t know what triggers this situation, because sometimes the problem starts as soon as the file is open, but sometimes after a series of actions or edits. The file that might trigger it is irrelevant, even a newly created one can do it. To work it around, Calc has to be stopped and then it would keep the expected behaviour for a longer or shorter while, until the bug starts again. Sometimes it starts from the first action. Of course I tried to set and reset all the options related to text wrapping for all the cells in the sheet in the Ctrl 1 options, but it doesn’t make a difference; Calc ultimately loses its usual behaviour. Tested on two computers Windows 7 and 10, even with a new profile. Steps to Reproduce: ↑ Actual Results: Cells are automatically and not expectedly transformed into active “Wrap text automatically”. Expected Results: Work the way previous Calc versions worked. Don’t change behaviour in the middle of the action flow. Don’t set “Wrap text automatically” Reproducible: Always User Profile Reset: Yes Additional Info: Please don’t release new “features” that are not thoroughly tested and create regressions.
By any chance, are the cells in which this happens including text with manual line breaks? Whichever the answer, we need a sample file to replicate the behavior. The file should rather be not saved by LO 24.2, so we could try to replicate the influence of opening it "for the first time" with LO 24.2 and see the modified behavior. IOW, please attach a file created/saved with an earlier version, that in your system shows the unwanted behavior when opened with 24.2 (but not yet saved with that latter version). Please keep in mind that the file will be publicly available.
Most cells, if not all, don’t contain line breaks. I could reproduce the problem this morning even with a new empty file from a new profile. So I don’t think a test file would help advance the problem in any way but it would be time lost. I can’t predict when Calc goes awry. I could create a short screen capture, but besides proving it, how could it be useful? However this problem appears so consistently on my computers, sometimes after a few hours, sometimes from the start.
I can only say that introducing a manual line break triggers the wrap text attribute in 24.2. This was not happening in 7.6. I reported the same as part of my post in bug 97106 comment 12. There might be other issues related to column width and row height. Without a sample worksheet (as minimal as possible), there is no way to guess what exactly you are seeing on your screen.
(In reply to maison from comment #2) >I can’t predict when Calc goes awry. I could create a > short screen capture, but besides proving it, how could it be useful? Well a screencast would actually be useful.. It gives some visual on what you're experiencing and doing. A description is rather abstract
Created attachment 192530 [details] First test file. As you start moving through the 3 cells, the “Wrap text automatically” option is set its way for each cell again.
Created attachment 192531 [details] Second test file. Not only that, but the cell alignment goes awry as well.
So, I managed to construct two test files with a slight variation. First, I have to retract the fact that the problem is visible on new and empty files (I was testing several things that made me confused). But the good news is that it’s tested and reproducible on 24.2. Contrary to the other referenced bug, it has nothing to do with xls files (I used native ods) and it is not dependable on formulas. The trigger is when you leave a cell that contains a line break, then Calc goes crazy. 1ˢᵗ file: Just move through the three cells. See line 3 expanding out of nowhere if you leave it first. Watch the undo list stack up with useless “attributes”. See Calc asking you to save the file when you close it. (Although not exactly the same thing, will bug 156431 ever be solved?) 2ⁿᵈ file: It has the same content, but I happened to define a cell height — just the default height. Browse through the cells. See how NOT ONLY word wrapping is affected, but the CELL ALIGNMENT as well: the last cells change their visible content. This bug is so workflow‐breaking for me that unfortunately I have to revert to 7.2 and not upgrade until it is resolved.
(revert to 7.6.4 rather, but that’s irrelevant)
Confirm comment 3 (didn't test comment 4) Version: 24.8.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: 4d381b54d1c598c181b4a21a8bf0db86eb4668d1 CPU threads: 4; OS: Windows 6.3 Build 9600; UI render: Skia/Raster; VCL: win Locale: nl-NL (nl_NL); UI: en-US Calc: CL threaded as reported not in Version: 7.6.3.0.0+ (X86_64) / LibreOffice Community Build ID: 35f19e5cb93ce218787904e99c2bedfd40e725cc CPU threads: 4; OS: Windows 6.3 Build 9600; UI render: Skia/Raster; VCL: win Locale: nl-NL (nl_NL); UI: en-US Calc: CL threaded
(In reply to maison from comment #5) > Created attachment 192530 [details] > First test file. As you start moving through the 3 cells, the “Wrap text > automatically” option is set its way for each cell again. This seems to have begun at the below commit in bibisect repository/OS linux-64-24.2. Adding Cc: to Paris Oplopoios ; Could you possibly take a look at this one? Thanks d536a038969c482dff40481d849d8671a9ac7f5f is the first bad commit commit d536a038969c482dff40481d849d8671a9ac7f5f Author: Jenkins Build User <tdf@maggie.tdf> Date: Thu Nov 23 16:18:50 2023 +0100 source 17e362e56f9e15d0214c441e632c91d22e58519d 159758: tdf#158252 sc: Enable text wrapping when inputting line breaks in cell | https://gerrit.libreoffice.org/c/core/+/159758
To simplify and summing up: When a cell contains at least one manual line break, the Wrap Text attribute for that cell is automatically and _forcefully_ (re-)applied. We now cannot have a cell that contains manual line breaks that would not have the Wrap Text attribute. Users should be able to use these 2 items independently. This seems to be both, a regression (in general) and an implementation error (of the patch mentioned in comment 10).
Thanks for the summary, ady. I hope the cell alignment is checked as well with the second test file, because it might be a separate problem or a side effect.
Increasing importance..
I agree that this sounds like an important and embarrassing bug. I can't help but wonder if this arose from attempts to address the long-standing issue that LibreOffice Calc does not reliably automatically adjust row height to fit the current length of all plain text wrapped cells on a row. I have not yet found a tracker issue for that bug, but I am searching.
*** Bug 159834 has been marked as a duplicate of this bug. ***
*** Bug 159351 has been marked as a duplicate of this bug. ***
An update on this behavior. While now tdf#159938 is solved (LO Dev. built on 2024-02-29), which allows to *unset* the wrap text attribute and save it, we still have a problem in tdf#159690. 1. On an empty cell, introduce text that includes a manual line break (using [CTRL]+[ENTER] where the manual line break should be located within the text). 2. Press [ENTER] to finish the introduction of the text (which includes the manual line break). 2. Move the focus back to the above cell. At the moment we finished editing the cell, it also received the Wrap Text attribute, just because there is a manual line break in it. Before LO 24.2.0, the Wrap Text was not automatically applied (which was/is the expected behavior). So, now that tdf#159938 is solved, the Wrap Text is not necessarily _forced_ (i.e. we can unset it and save), but it is still automatically initially applied.
I hoped to see this bug resolved in 24.2.1, but it’s not yet.
Created attachment 193524 [details] Francewhoa---Test_File---Zombie_Auto_Wrap---V1.ods Starting with this comment, I'm adding a few files Then I'll add a comment to confirm this challenge with recently released 24.2.2.2. Including both our steps to reproduce and some new information that might be useful to resolve this challenge.
Created attachment 193525 [details] Francewhoa---Screenshot---1---Deactivated_wrap---V1.png
Created attachment 193526 [details] Francewhoa---Screenshot---2---1st_line_without_wrap---V1.png
Created attachment 193527 [details] Francewhoa---Screenshot---3---1st_line_with_zombie_wrap---V1.png
Created attachment 193528 [details] Francewhoa---Screenshot---4---Forced_zombie_wrap---V1.png
This is to confirm this challenge. Using Calc 24.2.2.2. Also confirming that we could not reproduce this challenge with Calc ≤ 7.6.4 Adding a manual line break, then press "Enter" key, forces a not needed automatic wrap text Both me and the Ubertus.Org team would be happy, as volunteer, to contribute testing new versions and writing documentation, if needed. Using the LO from https://flathub.org/apps/org.libreoffice.LibreOffice --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- Below is the same as above. But with detailed steps and screenshots if you're interested in those. --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- Steps to Reproduce: 1. Using Calc version 24.2.2.2, add text to a cell with a manual line break. For example, the cell "A1". Adding at least one manual break is important. As it triggers this challenge 100% of the time. Alternatively, use the attached already configured "Francewhoa---Test_File---Zombie_Auto_Wrap---V1.ods" file. 2. Using the "Format Cells" window, deactivate "Wrap text automatically" for cell "A1". This screenshot https://bugs.documentfoundation.org/attachment.cgi?id=193525 shows this config. 3. This screenshot https://bugs.documentfoundation.org/attachment.cgi?id=193526 shows that the cell "A1" presently does not have any wrap text. 4. Edit this cell content. For example, add or remove a letter in the text. Then press "Enter" key to validate your edit. 5. Somehow, Calc automatically forced reactivated the not needed "Wrap text automatically" configuration. In other words, a Zombie-Wrap (joke ;). The attached screenshots https://bugs.documentfoundation.org/attachment.cgi?id=193527 and https://bugs.documentfoundation.org/attachment.cgi?id=193528 show this challenge. --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- Narrowing Down: Below is what we found while testing. Which might be useful to resolve this challenge. • Using Calc 24.2.2.2, using this file https://bugs.documentfoundation.org/attachment.cgi?id=193524 Using the steps to reproduce above, at step 3, instead of pressing "Enter" key, press on "Escape" (Esc) key. Your edit is lost. But the Zombie-Wrap is not forced. This means that somehow, pressing "Enter" key triggers this challenge. • Using a version of Calc older than 24.2.2.2, I forgot to write down which one exactly, most likely the before last version or the second before last version. Using the steps to reproduce above, complete the first 3 steps only. Then left click on cell "A1" to select it. Then save the document. The Zombie-Wrap is forced. This means that somehow, when a selected cell includes a break line, when the user save the document, the Zombie-Wrap is triggered. This challenge is resolved with 24.2.2.2. But the other challenge above with the "Enter" key is not yet resolved. • Also using a version of Calc older than 24.2.2.2, again using the steps to reproduce above, complete the first 3 steps only. Then left click on cell "A4" to select it. In the attached file this cell is empty. Then save the document. The Zombie-Wrap is not forced. Again, this confirms that somehow, only when a selected cell includes a break line, when the user save the document, the Zombie-Wrap is triggered. Again, this challenge is resolved with 24.2.2.2. But the other challenge above with the "Enter" key is not yet resolved. --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- Using: • LibreOffice 24.2.2.2 from https://flathub.org/apps/org.libreoffice.LibreOffice • Debian 12 Bookworm 64 bits • GNOME 43.9 • Wayland
We tested LO 24.2.3.2. Which was release today, May 3rd, 2024. This challenge is still present. Using Flatpak from https://flathub.org/apps/org.libreoffice.LibreOffice