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
I wonder if this very annoying bug will be taken into account in some way. I did not find any way of upvoting it to make it more visible to developers.
Thanks for your comment JulesFox :) Very annoying bug indeed. This Buzilla software does not have upvoting I'll let the developers speak for themselves about their preferred type of notification. For most developers, their preferred format is what you did. Simply add a comment confirming that you're affected by this challenge. For your future comments, if you're interested to contribute to speeding up a resolution, I suggest including this minimum information: The name of your operating system and its version; The version of your LibreOffice. For example: Debian 12 Bookworm. LibreOffice 24.2.2.2. Optionally, if you are interested to both show interest and receive email notifications about future updates for this ticket. At the top of this page, next to the "CC List", click on "Edit" link. Then, if not already done, add your email. The email you choose is publicly visible. I suggest using an appropriate email address so that you don't receive spam by spammer's bots.
This is to confirm that this challenge can be reproduced with LO: • Version: 24.2.4.2 (X86_64) • Build ID: 51a6219feb6075d9a4c46691dcfe0cd9c4fff3c2 • Release: June 27th, 2024 • Package: Flatpak from https://flathub.org/apps/org.libreoffice.LibreOffice
Connections NYT - famous puzzle game and has daily puzzles released to challenge the player's thinking. https://connectionsnytgame.io
This is to confirm that this challenge can be reproduced with LO: • Version: 24.2.5.2 (X86_64) • Build ID: bffef4ea93e59bebbeaf7f431bb02b1a39ee8a59 • CPU threads: 8; OS: Linux 6.7; UI render: default; VCL: gtk3 • Locale: fr-CA (fr_CA.UTF-8); UI: fr-FR • Package: Flatpak from https://flathub.org/apps/org.libreoffice.LibreOffice • Calc: threaded • Release: July 12th, 2024
Donghuastream brilliantly bridges the worlds of anime and donghua, offering a fresh perspective with its unique blend of styles. It’s a must-watch for fans seeking diverse and engaging storytelling from both East Asian animation traditions. https://donghuastream.me/
This is to confirm that this challenge can be reproduced with LO: • Version: 24.8.0.3 (X86_64) • Build ID: 0bdf1299c94fe897b119f97f3c613e9dca6be583 • Release: August 22nd, 2024 • CPU threads: 8; OS: Linux 6.9.7; UI render: default; VCL: gtk3 • Locale: fr-CA (fr_CA.UTF-8); UI: fr-FR • Package: Flatpak from https://flathub.org/apps/org.libreoffice.LibreOffice • Calc: threaded
It sounds like a frustrating bug in Calc, especially with the automatic "Wrap text automatically" feature unexpectedly activating. This issue disrupts workflow and fills up the undo list with unnecessary actions. Hopefully, a fix will restore the stability seen in previous versions. https://luciferdonghua.one/
Reproducible with Version: 25.2.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: c8eb95e8407ef24436e0e8e218dce535df6bb2e5 CPU threads: 4; OS: Windows 10 X86_64 (10.0 build 10240); UI render: Skia/Raster; VCL: win Locale: ja-JP (ja_JP); UI: ja-JP Calc: threaded
*** Bug 163099 has been marked as a duplicate of this bug. ***
*** Bug 163150 has been marked as a duplicate of this bug. ***
(In reply to maison from comment #7) > 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. Watch Chinese Animegn Lucifer Donghua / Mister Donghua / Japanese Anime In English Sub, Luciferdonghua, all Series, Movies, BTTH ,Soul Land 2 Watch Ads Free on https://luciferdonghua.cc/
Watch Chinese Animegn Lucifer Donghua / Mister Donghua / Japanese Anime In English Sub, Luciferdonghua, all Series, Movies, BTTH ,Soul Land 2 Watch Ads Free on https://luciferdonghua.cc/
Justin Luth committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/dafb629f4f5739e326fdf6b3f072fe139ed27c3b tdf#161453 tdf#158252 tdf#159690 Revert "sc: Fix wrapText ... It will be available in 25.2.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Justin Luth committed a patch related to this issue. It has been pushed to "libreoffice-24-8": https://git.libreoffice.org/core/commit/be9e77ef1e1180e86b1669b4fb176713ac54a9ba tdf#161453 tdf#158252 tdf#159690 Revert "sc: Fix wrapText ... It will be available in 24.8.3. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Justin Luth committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/55a8fce5d76bba0657ed76c85439fac8d1d00c8d tdf#159690 tdf#159938 Revert "tdf#158252 sc: Enable text wrapping... It will be available in 25.2.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Justin Luth committed a patch related to this issue. It has been pushed to "libreoffice-24-2": https://git.libreoffice.org/core/commit/a6bc95646b0b872375d710afbea953189d2a117a tdf#161453 tdf#158252 tdf#159690 Revert "sc: Fix wrapText ... It will be available in 24.2.7. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Justin Luth committed a patch related to this issue. It has been pushed to "libreoffice-24-8": https://git.libreoffice.org/core/commit/c1d2902b64dc02026f7842a43e540283b67df13d tdf#159690 tdf#159938 Revert "tdf#158252 sc: Enable text wrapping... It will be available in 24.8.3. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Justin Luth committed a patch related to this issue. It has been pushed to "libreoffice-24-2": https://git.libreoffice.org/core/commit/be818a6d53f9b5dfa0d23b807463b1c00d67800d tdf#159690 tdf#159938 Revert "tdf#158252 sc: Enable text wrapping... It will be available in 24.2.7. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
There are no zombies that appear infinitely. thank you. --- No zombie wrap Version: 24.8.3.0.0+ (X86_64) / LibreOffice Community Build ID: 81268254b69ae1a9acbe52e4aa63910343f4987c CPU threads: 4; OS: Windows 10 X86_64 (10.0 build 10240); UI render: Skia/Raster; VCL: win Locale: ja-JP (ja_JP); UI: ja-JP Calc: threaded No zombie wrap Version: 25.2.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: 99c7cf2816b2d0016832552dbe6c55456ade42e0 CPU threads: 4; OS: Windows 10 X86_64 (10.0 build 10240); UI render: default; VCL: win Locale: ja-JP (ja_JP); UI: ja-JP Calc: threaded
*** Bug 163422 has been marked as a duplicate of this bug. ***
Manual line breaks can trigger automatic Wrap Text behavior in Calc, causing rows to expand unexpectedly as you navigate through cells—an issue similar to finding a reliable app like GoGoAnime for Mac( https://www.gogoanimemod.com/gogoanime-for-mac/ ) to manage preferences seamlessly.