Hi, This is a bug that concerns the new 5.3.0 feature 'Table Styles'. Basically when I choose a style or I scroll through different styles, I cannot go back to my orignial table format, even if I undo a number of times. Things like font size, bold settings are lost and have to be set again. Extremely annoying when dealing with large tables. Dangerous when you don't have another copy of the document to import the previous settings of the table.
Thank you for reporting the bug. Unfortunately without clear steps to reproduce it, we cannot track down the origin of the problem. Please provide a clearer set of step-by-step instructions on how to reproduce the problem. I have set the bug's status to 'NEEDINFO'. Please change it back to 'UNCONFIRMED' once the steps are provided
Created attachment 130955 [details] Bug on Table Styles How to reproduce the bug: 1- Open the file and click on the table; 2- Choose any of the table styles (e.g. 3D, Blue, whatever...) 3- Do CTRL+Z several times to revert to the original table. Result: Impossible to revert to original table. Settings such as Font Name, Font Size, Bold (and possible others) are lost and cannot be recovered.
Hi nuno360, Ctrl+Z and Ctrl+Y works for me with LO 5.3.0.1 Build ID: 3b800451b1d0c48045de03b5b3c7bbbac87f20d9 CPU Threads: 2; OS Version: Windows 6.1; UI Render: default; Layout Engine: new; Locale: en-US (fr_FR); Calc: CL and upper versions. With which OS do you work? In Edit Menu, you should find after application of a Table style Undo: AutoFormat Table Does this work? Is Ctrl+Z active for others features than Table styles?
No, doing 'Undo: AutoFormat Table' does not work, i.e. the table does not go back to its original settings. Did you try the document I have attached? The Format of the table does NOT go back to the original settings. This happens on Win 10 and Lubuntu 16.04 Version: 5.3.0.3 Build ID: 7074905676c47b82bbcfbea1aeefc84afe1c50e1 CPU Threads: 4; OS Version: Windows 6.2; UI Render: default; Layout Engine: new; Locale: en-GB (en_GB); Calc: group
Confirming with: Version: 5.4.0.0.alpha0+ Build ID: a296a69c984b17cfbcd249cf6bdc191d08dff2a6 CPU Threads: 4; OS Version: Windows 6.19; UI Render: default; TinderBox: Win-x86@42, Branch:master, Time: 2017-02-06_00:00:55 Locale: nl-NL (nl_NL); Calc: CL The text in column 'A' isn't bold anymore after applying table style and undoing it.
Also found in: Versie 4.0.0.3 (Bouw-id: 7545bee9c2a0782548772a21bc84a9dcc583b89) but not in: LibreOffice 3.5.7.2 Build ID: 3215f89-f603614-ab984f2-7348103-1225a5b
I can confirm that the table text was Times New Roman 10pt and top row & first column headers were bold, but after undoing the table style the text is Liberation Serif 12pt and none of the headers are bold. Version: 5.4.0.0.alpha0+ Build ID: 74ccd02eda2d6325a27266fd935aba29b3d75020 CPU threads: 2; OS: Linux 4.4; UI render: default; VCL: gtk2; TinderBox: Linux-rpm_deb-x86_64@70-TDF, Branch:master, Time: 2017-04-27_23:51:14 Locale: en-US (en_US.UTF-8); Calc: group
Bibisected on Linux with 43all, but unfortunately there are builds where it crashes upon Autoformat. There are only 'skip'ped commits left to test. The first bad commit could be any of: d90609a23df275b46b672a01729a6ad7715eb618 21974bfa867971881326fe3694bc1fb365f20ae1 2e7c0beeab83f1a84424d4762144b1cfac32f956 a7a51689878f5428c3934558f820fb65af04fedb We cannot bisect more! As there were relatively few, I grabbed the source commits of the ranges for convenience in case someone wants to dig into it: https://cgit.freedesktop.org/libreoffice/core/log/?qt=range&q=d6a32eee46ed38b61540287bb53eaf310869d601...9e8957de203bb9abb208516ad32aee9527feb67b https://cgit.freedesktop.org/libreoffice/core/log/?qt=range&q=9e8957de203bb9abb208516ad32aee9527feb67b...9afb6e1e38c362a768e8e981f7b03cf8bcaf22cf https://cgit.freedesktop.org/libreoffice/core/log/?qt=range&q=699e7d9e4081942bb0ad73e9be73f90a26d0c2f7...d6a32eee46ed38b61540287bb53eaf310869d601 https://cgit.freedesktop.org/libreoffice/core/log/?qt=range&q=2a360b68475d6fff5b6618feddb0b52f3a4a2373...699e7d9e4081942bb0ad73e9be73f90a26d0c2f7
I still repro Version: 6.4.0.0.alpha0+ (x86) Build ID: c30ea50dd2b1c557dfbefc1a4c660fbf2402a604 CPU threads: 4; OS: Windows 6.3; UI render: default; VCL: win; TinderBox: Win-x86@42, Branch:master, Time: 2019-06-04_22:59:40 Locale: it-IT (nl_NL); UI-Language: en-US Calc: threaded
@Jim: I thought you might be interested in this issue
Hi all, This was a very challenging bug fix for me. I learned much about the undo redo code. Here is a link to a patch to fix this bug: https://gerrit.libreoffice.org/#/c/73937/
(In reply to Jim Raykowski from comment #11) > Hi all, > > This was a very challenging bug fix for me. I learned much about the undo > redo code. > > Here is a link to a patch to fix this bug: > https://gerrit.libreoffice.org/#/c/73937/ @Jim Many thanks for all the effort :-). Really appreciated! What a small change can do.. It looks rather simple when looking at the patch :D. You *only* need to find the right line(s) in the code; being a needle in a haystack.
Jim Raykowski committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/+/adcb7bacb452dccde70b20a902f5c1f23f37913f%5E%21 tdf#105799 Fix vector use bug It will be available in 6.4.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.
The cause of this regression was https://cgit.freedesktop.org/libreoffice/core/commit/?id=b3473b9d227df79a383d09c2f2ebf6d6eebf3697 fdo#50896 SfxItemSets can contain emtpy element
Cherry-picked to 6.3 branch -> https://gerrit.libreoffice.org/#/c/74151/ Considering it's a bug since at least LibreOffice 4.0, I don't think it should be cherry-picked to 6.2 branch
(In reply to Xisco Faulí from comment #15) > Cherry-picked to 6.3 branch -> https://gerrit.libreoffice.org/#/c/74151/ > Considering it's a bug since at least LibreOffice 4.0, I don't think it > should be cherry-picked to 6.2 branch Note: the autoformat feature is more prominent since I think 6.0.. OTOH: number of complains is rather low..
Jim Raykowski committed a patch related to this issue. It has been pushed to "libreoffice-6-3": https://git.libreoffice.org/core/+/1da4fb3d3438355c04ce616563422a6a51943c11%5E%21 tdf#105799 Fix vector use bug It will be available in 6.3.0.1. 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.
Jim Raykowski committed a patch related to this issue. It has been pushed to "libreoffice-6-2": https://git.libreoffice.org/core/+/772ceeaf8df89e392494b80efc1823b0e6917575%5E%21 tdf#105799 Fix vector use bug It will be available in 6.2.6. 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.
Verified in Version: 6.4.0.0.alpha0+ Build ID: 52800731baf9fcb88e54d60de5585640c8f97f7b CPU threads: 4; OS: Linux 4.15; UI render: default; VCL: x11; Locale: ca-ES (ca_ES.UTF-8); UI-Language: en-US Calc: threaded @Jim Raykowski, thanks for fixing this issue!