https://bugs.documentfoundation.org/show_bug.cgi?id=161243

Stéphane Guillou (stragu) <[email protected]> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
            Version|7.6.7.2 release             |6.1.0.3 release
           See Also|                            |https://bugs.documentfounda
                   |                            |tion.org/show_bug.cgi?id=11
                   |                            |7189
                 CC|                            |[email protected],
                   |                            |stephane.guillou@libreoffic
                   |                            |e.org
         Resolution|---                         |DUPLICATE
             Status|UNCONFIRMED                 |RESOLVED
           Keywords|                            |bibisected, bisected

--- Comment #2 from Stéphane Guillou (stragu) 
<[email protected]> ---
Thanks for the report. The same happens if inserting a row with the Table
toolbar, which makes it look like bug 126008, a known issue about AutoFormat
styles (and might depend on availability of such styles between version of LO).

But you are right that the macro method would work without removing formatting
back in 6.0.0.3, while the toolbar command would remove it. However, you can
still reproduce with the macro by first placing the cursor inside the table
before running it.
The macro method started failing directly in 6.1.

Bibisected with linux-64-6.1 to first bad build
[54727c22fdde9ad29e59fabeaa63df9bf9a90909] which is:

commit  137c38a1ba01c51c421f695e1558d2c1499c6627
author  Jim Raykowski <[email protected]>       Sat Apr 28 22:20:51 2018 -0800
committer       Michael Stahl <[email protected]>    Mon May 21 22:26:37
2018 +0200
tdf#117189 Fix table InsertRow redo
Reviewed-on: https://gerrit.libreoffice.org/53618

See this relevant comment from the bug report:

(In reply to Jim Raykowski from bug 117189 comment #7)
> [...]
> So a new approach to fix this bug is to move the cursor into the table when
> restored with redo. This approach can be tested manually by removing this
> patch or using a version before this patch was merged.
...which confirms my observation about moving the cursor.
Not calling this a regression, as it only made a pre-existing issue visible
(Jim can confirm?).

*** This bug has been marked as a duplicate of bug 126008 ***

-- 
You are receiving this mail because:
You are the assignee for the bug.

Reply via email to