Bug 149570 - Can't undo removing columns / rows until leaving the table or adding to history stack (steps in comment 4)
Summary: Can't undo removing columns / rows until leaving the table or adding to histo...
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Impress (show other bugs)
Version:
(earliest affected)
7.3.0.0 alpha1+
Hardware: All All
: medium normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords: bibisected, bisected, regression
Depends on:
Blocks: ImpressDraw-Tables Undo-Redo
  Show dependency treegraph
 
Reported: 2022-06-14 22:24 UTC by Eyal Rozenberg
Modified: 2023-03-18 08:09 UTC (History)
5 users (show)

See Also:
Crash report or crash signature:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Eyal Rozenberg 2022-06-14 22:24:10 UTC
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.
Comment 1 m_a_riosv 2022-06-15 01:03:24 UTC
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.
Comment 2 Rafael Lima 2022-06-15 21:13:16 UTC
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.
Comment 3 Eyal Rozenberg 2022-06-15 21:19:21 UTC
(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...
Comment 4 Stéphane Guillou (stragu) 2023-03-11 09:41:43 UTC
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.
Comment 5 Stéphane Guillou (stragu) 2023-03-11 20:17:38 UTC Comment hidden (obsolete)
Comment 6 Caolán McNamara 2023-03-13 10:31:14 UTC
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.
Comment 7 Stéphane Guillou (stragu) 2023-03-15 21:10:12 UTC
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?
Comment 8 Tomaz Vajngerl 2023-03-17 10:06:17 UTC
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.
Comment 9 Eyal Rozenberg 2023-03-17 10:20:25 UTC
(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?
Comment 10 Tomaz Vajngerl 2023-03-18 08:09:33 UTC
(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.