Bug 154066 - Unable to undo attributes part of cell's area
Summary: Unable to undo attributes part of cell's area
Status: RESOLVED DUPLICATE of bug 153644
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Calc (show other bugs)
(earliest affected) beta1+
Hardware: All All
: medium normal
Assignee: Not Assigned
Keywords: bibisected, bisected, regression
Depends on:
Reported: 2023-03-08 11:53 UTC by Roman
Modified: 2023-06-13 22:37 UTC (History)
3 users (show)

See Also:
Crash report or crash signature:

Calc_list (97.18 KB, image/png)
2023-03-08 11:54 UTC, Roman
Calc_list_1 (60.51 KB, image/png)
2023-03-09 12:27 UTC, Roman

Note You need to log in before you can comment on or make changes to this bug.
Description Roman 2023-03-08 11:53:19 UTC
Incorrect work with applying styles and values

Steps to Reproduce:
1. Run Calc
2. Select more than 5 columns
3. Apply Border Borders
4. Press Ctrl+Z
5. look Calc_list

Actual Results:
The undo action was performed only on the first 5 columns

Expected Results:
Cancel all border selection

Reproducible: Always

User Profile Reset: No

Additional Info:
On version Reverse history. And apparently it was corrected.
The entire sheet in such cases should be single, and not partial.
Comment 1 Roman 2023-03-08 11:54:03 UTC
Created attachment 185840 [details]
Comment 2 ady 2023-03-08 13:13:33 UTC
It is worse than that.

1. Open new Calc
2. Select A1:C3
3. Apply "Outer border and All inner lines" (one action)
4. Click on E7
5. [CTRL]+[Z] > note diff. effect in first column vs. the other 2 columns.
6. Select A1:E7
7. Apply "Outer border and All inner lines" (one action)
8. [CTRL]+[Z] > note diff. effect in first few rows vs. last few rows.

This procedure can be cycled with bigger and bigger areas. The rows/columns that were left with a border (i.e. where the prior undo action was not successful) will remain with the border attribute in the next [CTRL]+[Z] cycle too.

At first it would seem that the only difference is in columns (undo on column A is OK, fails on the others), but the above steps show that this is not limited to "all_but_column_A" column.

Moreover, if the procedure starts on a different cell (e.g., from D5 instead of A1), then the initial [CTRL]+[Z] doesn't seem to be successful on any of the relevant cell range.

This "progressive" behavior, especially regarding column A vs. other columns, has been seen recently in more than one report; bug 153913 is one example.

Setting to version as earliest *for now*.
Comment 3 m_a_riosv 2023-03-08 23:12:55 UTC

*** This bug has been marked as a duplicate of bug 154044 ***
Comment 4 Roman 2023-03-09 12:25:27 UTC
I confirm after cleaning the profile, only one column A remains.
The profile is still there.
Подтверждаю после чистки профиля остался только один столбец А.
Профиль есть остался.
Comment 5 Roman 2023-03-09 12:27:31 UTC
Version: (X86_64) / LibreOffice Community
Build ID: fcbaee479e84c6cd81291587d2ee68cba099e129
CPU threads: 12; OS: Linux 5.15; UI render: default; VCL: gtk3
Locale: ru-RU (ru_RU.UTF-8); UI: ru-RU
Calc: threaded
Comment 6 Roman 2023-03-09 12:27:49 UTC
Created attachment 185857 [details]
Comment 7 Roman 2023-05-19 08:21:09 UTC
This problem exists when upgrading the LO version
Данная проблема существует при обновлении версии LO
Comment 8 ady 2023-06-02 17:18:33 UTC
STR of comment 2, still repro as of LO 7.6.alpha.

The effects in this bug 154066 are worse than in bug 154044:
* not only column A is affected;
* not only the first applied attribute is affected.
Comment 9 Stéphane Guillou (stragu) 2023-06-13 22:37:19 UTC
With core commit 9e2d48b9e04f7ea895fb095699c32ed8a44eb129, the issue started with the inability to apply formatting to the whole of a cell range that does not contain data in its edges.
Behaviour as described in comment 2 was bibisected with linux-64-7.4 repo to commit ecdde2cb463610623dc25454f67ba99bb8c86fca which points to core commit:

commit 970ff17f47731be788ec34c0c8ddf3fb2c24ceac
author	Luboš Luňák <l.lunak@collabora.com>	Mon May 30 16:33:15 2022 +0200
committer	Luboš Luňák <l.lunak@collabora.com>	Mon May 30 21:20:54 2022 +0200
fix setting cell borders for unallocated cells
First of all, it should not be clamped to allocated columns. Second, 06d3294502413a231e5c5265609862c7f67a2f2b incorrectly handled
unallocated columns by setting the attribute for all rows, instead
of handling the inner ones differently.
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/135131

So, first commit broke things, second commit was a partial fix.

Still same root cause as bug 154044, but marking as duplicate of bug 153644 instead as the bibisect and description match.

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