Most, or all, operations on tables, or within tables cannot be undone (i.e. Undo doesn't work for them). This includes adding and removing columns and rows, and formatting of cells or cell ranges (e.g. colors, borders etc.) I would think this bug would be a dupe, but I couldn't find one.
Repro. Version: 7.4.0.0.alpha1+ (x64) / LibreOffice Community Build ID: 66b1ebd4ddc7127a923bf81eb569e7f99dd52022 CPU threads: 4; OS: Windows 10.0 Build 19044; UI render: Skia/Raster; VCL: win Locale: es-ES (es_ES); UI: en-US Calc: threaded Only works before left the cell where de data was modified or insertions/deletions were done.
Impress tables have too many bugs =( I use them all the time and it's impossible to finish preparing a presentation without running across a table bug in Impress.
(In reply to Rafael Lima from comment #2) > Impress tables have too many bugs =( > > I use them all the time and it's impossible to finish preparing a > presentation without running across a table bug in Impress. Yeah, I don't understand why Impress tables aren't one of the annual foci for a tender, or allocated some serious developer time. They're quite the embarrassment IMHO. This and a zillion formatting gaffes...
I could undo addition / deletion of columns and rows in: Version: 7.6.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: 082d009b6a156faa74c9966b0dffc5fa6ce22287 CPU threads: 8; OS: Linux 5.15; UI render: default; VCL: gtk3 Locale: en-AU (en_AU.UTF-8); UI: en-US Calc: threaded ...but I had to click out of the table first. Formatting of borders couldn't be undone, which is already tracked in bug 142540. I'm refocusing this ticket on the column / row removal issue, as they are probably different enough to be tackled separately. Steps to reproduce: 1. Insert > Table > OK 2. Without clicking into the table, use toolbar to successively add a column, and a row: it is still possible to undo these operations. 3. Use toolbar to remove a row and a column Result: Can't undo until I click into the table, then out again. Or alternatively, until add something to the history (e.g. insert a shape). The steps can be also done a bit differently: if you click inside the table at Step 2, before adding rows, you will only have to click out of the table to make undo operations available. Seems to be a regression: I can undo a row / column removal without leaving the table in: Version: 7.3.7.2 / LibreOffice Community Build ID: e114eadc50a9ff8d8c8a0567d6da8f454beeb84f CPU threads: 8; OS: Linux 5.15; UI render: default; VCL: gtk3 Locale: en-AU (en_AU.UTF-8); UI: en-US Calc: threaded But I can't in: Version: 7.4.5.1 / LibreOffice Community Build ID: 9c0871452b3918c1019dde9bfac75448afc4b57f CPU threads: 8; OS: Linux 5.15; UI render: default; VCL: gtk3 Locale: en-AU (en_AU.UTF-8); UI: en-US Calc: threaded Will bibisect today.
Bibisected with linux-64-7.4 repo to first bad commit 6510e2270f35e0faffcb66742917c9674de5f5f3 which points to core commit: commit ae0e7e3918284c31a91acca0f733919926ae3a62 author Caolán McNamara <caolanm@redhat.com> Thu Apr 14 11:20:23 2022 +0100 committer Caolán McNamara <caolanm@redhat.com> Thu Apr 14 16:10:20 2022 +0200 tree c23d0a76fdf2fdaa73b7c352428d7dd6deb723bb parent 590323f4235e5ec3de2dc6dee28a4f03288ac6d7 tdf#141812 keep focus in an impress table cell when row/col deleted Change-Id: I3b396ba92039bad657ca159002598a271b68a79d First tag is 7.4.0.0.alpha1 Caolán, can you please have a look?
I bisect to: commit c175c1dc19d0edc8ca66e39f0b4b8af04e3d6c87 Author: Tomaž Vajngerl <tomaz.vajngerl@collabora.co.uk> Date: Thu Oct 7 16:48:46 2021 +0200 svx: Don't end text edit mode for all views This allows multiple views to not disturb each other editing inside a impress document. With the ending of text edit for all views still enabled, one view can cancel other views text editing just by moving or resizing a unrelated shape in the document. To make this possible we also need a view-local undo manager for the text edit mode, which is independent of the document undo manager. When the text edit mode ends, all the changes will be added as one change to the document undo stack. This prevents any conflicts in the undo stack that could be made when 2 views are editing the same document at the same time. This also adds the test for the new use case and changes the existing tests to reflect the change. Change-Id: I04edb4f91d7e111a490c946f7121cbca75f818d7 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/123220 Tested-by: Tomaž Vajngerl <quikee@gmail.com> Reviewed-by: Tomaž Vajngerl <quikee@gmail.com> and the commit message does seem to match the observed behavior. Can't seem to access the "outer" undo stack with col/row remove it it when inside the inner editeng editing.
Thanks, Caolán. I should have clarified the steps I used for my bisect: 1. Open Impress or Draw 2. Insert table 3. Add row: undo is possible 4. Remove row: undo is greyed out Before commit ae0e7e3918284c31a91acca0f733919926ae3a62, it was possible to undo the row removal without extra steps. But now I can see how your change in focus simply made a pre-existing issue pop-up when following my steps. Before that commit, one needs to then click inside the table as a step 5 to see that the undo was already unavailable. Quikee, any thoughts?
This change was necessary to make it possible to make it properly work with multiple views (which are used in LOKit and COOL to make collaboration work). Previous behavior always forced and exit from the edit box in all views when there was a new item added to the undo stack. This would mean that if someone was writing in an text box in impress and another user changed something somewhere on the same slide (could be even a different slide), all the changes performed by the first user would be reverted and he would be forced out of the text box. Another issue related to this was also that in a text box all the actions between entering and exiting the edit box would be made as 1 general action in the undo stack. The issue here is how this was done - on entering the edit mode of the text box every action would be written to the primary undo stack, on exiting the edit mode the whole undo stack was reverted (undo-ed to the state at the entering) and instead on single action was written. The code doing this was quite ugly and error prone - also not taking multiple views into account at all (which is why it forced exit edit mode when anything was added to the undo stack). The solution to this was to add a completely new undo stack on entering the edit mode and discarding it on exiting the edit mode and writing only one entry to the primary undo stack. The ugly thing is that the primary undo stack in the edit mode has now been exchanged with the a new - blank one, so you don't see the entries in the primary one anymore in the UI and can't undo out of it either. In general for the text boxes in impress this behavior is still kind-of acceptable, but for the tables, this is more annoying (especially if you don't know about it). One thing that we could do is to still somehow combine the 2 undo stacks at the UI level but still allow them to be independent.
(In reply to Tomaz Vajngerl from comment #8) > This change was necessary to make it possible to make it properly work with > multiple views (which are used in LOKit and COOL to make collaboration > work). Previous behavior always forced and exit from the edit box in all > views when there was a new item added to the undo stack. It was not _necessary_. You mean to say, it was a hack which avoided a problem by breaking the feature with which the problem manifstered. > This would mean that if someone was writing in an text box in impress and > another user changed something somewhere on the same slide (could be even a > different slide), all the changes performed by the first user would be > reverted and he would be forced out of the text box. So, let us file _that_ bug and fix it. > Another issue related to this was also that in a text box all the actions > between entering and exiting the edit box would be made as 1 general action > in the undo stack. ... which is also a bug, is it not? > In general for the text boxes in impress this > behavior is still kind-of acceptable, So, is it also possible to perform several distinct undoable tasks with a textbox? and that only this entering-the-edit-box thing prevents us from being able to undo them individually?
(In reply to Eyal Rozenberg from comment #9) > It was not _necessary_. You mean to say, it was a hack which avoided a > problem by breaking the feature with which the problem manifstered. As I said the change was necessary to make it work with multiple views / users. It's not a hack, it's actually conceptually the right way and the only way to do it that makes sense (concurrently). The hack was the initial code, which was hacking around with the primary undo stack. If there is a bug it's just something that tests don't cover and was missed during implementation. > So, let us file _that_ bug and fix it. That was fixed by the commit... > ... which is also a bug, is it not? It was intentionally done like that before and I just didn't change the behavior. It surely would be nicer to have all the actions even when you leave the editing mode append into the primary undo stack. > So, is it also possible to perform several distinct undoable tasks with a > textbox? and that only this entering-the-edit-box thing prevents us from > being able to undo them individually? It should be possible to just copy all the actions over, but I haven't explored that.