Bug 109412 - FORMATTING - Column Insert does not always insert a New column
Summary: FORMATTING - Column Insert does not always insert a New column
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Calc (show other bugs)
Version:
(earliest affected)
4.4.7.2 release
Hardware: x86-64 (AMD64) Linux (All)
: medium normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords:
Depends on:
Blocks: Cell-Management
  Show dependency treegraph
 
Reported: 2017-07-27 03:54 UTC by Stang
Modified: 2025-05-06 03:10 UTC (History)
2 users (show)

See Also:
Crash report or crash signature:


Attachments
Sample - Directions in text (7.14 KB, application/vnd.oasis.opendocument.spreadsheet)
2017-07-27 03:54 UTC, Stang
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Stang 2017-07-27 03:54:40 UTC
Created attachment 134886 [details]
Sample - Directions in text

This actually applies to both rows AND columns but will only discuss columns here.

When inserting a column it is usally a copy of the column to the left of the insert.  It should remove all information before the actual insert but it doesn't.

Attached sample has two sheets.  Demo:

1.  Sheet1 has background colors in cells A1:A5 and AMJ1:AMJ10.  Select Column A & insert column to LEFT.  Cells A1:A10 & B1:B5 now have background colors AND AMJ column is blank.  If an 'undo' is now selected, A1:A5 has background colors and column AMJ is blank.

2.  Again starting with original Sheet1, it has background colors in cells A1:A5 and AMJ1:AMJ10.  Delete column C.  Now the background colors are in cells A1:A5 and AMI1:AMI10 with a completely blank column AMJ!  AN 'undo' now has background colors in AMJ1:AMJ10.

3.  Using Sheet2, inserting columns left or right on columns B or C will also duplicate background colors depending upon which column and direction is chosen.

This is just an easy to visualize sample.  I came upon this problem because in an extension I have (Hatch Cells), I store information in "UserDefinedAttributes".  This causes problems when inserting new columns/rows because this information is checked to re-generate skewed patterns.  This information is never cleared for the inserted column.  There could very well be more fields which retain information upon an insert beside the two mentioned here.

In the #2 demo above it appears a NEW column is actually appended to the end of the columns.  If so, why couldn't this be done in other inserts?

The other question arises as to why a new column is allowed in the #1 demo above since cells in columns A & AMJ (full Sheet) contain information?  If there was data instead of this other information, the insert wouldn't be allowed.
Comment 1 Stang 2017-07-27 03:57:39 UTC
Also tested with Daily from 7/20/2017 - 6.0.0.0 x86-64 deb
Comment 2 raal 2017-07-27 15:21:31 UTC
(In reply to Stang from comment #0)
> 
> The other question arises as to why a new column is allowed in the #1 demo
> above since cells in columns A & AMJ (full Sheet) contain information?  If
> there was data instead of this other information, the insert wouldn't be
> allowed.

Please create new bug for this and add me to cc. Thank you
Comment 3 raal 2017-07-27 15:26:25 UTC
I can confirm  part 1) and partially 2- insert left is without background, but insert right replicate the background color.

Version: 6.0.0.0.alpha0+
Build ID: e0bafa78e3ad0df397d78cd65ad19bd5b07dc5f2
CPU threads: 4; OS: Linux 4.4; UI render: default; VCL: gtk2; 
TinderBox: Linux-rpm_deb-x86_64@70-TDF, Branch:master, Time: 2017-07-20_22:42:49
Comment 4 Stang 2017-07-27 20:43:36 UTC
raal - The reason you saw a partial was because of where you inserted from.  The column copied is ALWAYS the column to the left of the newly inserted column.  If you test using Sheet2, from column C, do an insert left & right to see what I mean.  One will insert with 10 colored background cells & the other with 5.  'Undo' after one insert (left) & before the other (right).
Comment 5 Stang 2017-12-23 23:49:52 UTC
This bug is still present in Beta of:

Version: 6.0.0.1
Build ID: d2bec56d7865f05a1003dc88449f2b0fdd85309a
CPU threads: 4; OS: Linux 4.8; UI render: default; VCL: gtk2; 
Locale: en-US (en_US.UTF-8); Calc: group
Comment 6 QA Administrators 2018-12-24 03:44:08 UTC Comment hidden (obsolete)
Comment 7 QA Administrators 2020-12-24 03:52:26 UTC Comment hidden (obsolete)
Comment 8 QA Administrators 2022-12-25 03:21:29 UTC Comment hidden (obsolete)
Comment 9 BogdanB 2023-05-06 11:59:55 UTC Comment hidden (obsolete)
Comment 10 ady 2023-05-06 13:30:10 UTC Comment hidden (obsolete)
Comment 11 BogdanB 2023-05-06 13:51:44 UTC
Setting back to New. Sorry.
Comment 12 QA Administrators 2025-05-06 03:10:37 UTC
Dear Stang,

To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year.

There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present.

If you have time, please do the following:

Test to see if the bug is still present with the latest version of LibreOffice from https://www.libreoffice.org/download/

If the bug is present, please leave a comment that includes the information from Help - About LibreOffice.
 
If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a comment that includes the information from Help - About LibreOffice.

Please DO NOT

Update the version field
Reply via email (please reply directly on the bug tracker)
Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not 
appropriate in this case)


If you want to do more to help you can test to see if your issue is a REGRESSION. To do so:
1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) from https://downloadarchive.documentfoundation.org/libreoffice/old/

2. Test your bug
3. Leave a comment with your results.
4a. If the bug was present with 3.3 - set version to 'inherited from OOo';
4b. If the bug was not present in 3.3 - add 'regression' to keyword


Feel free to come ask questions or to say hello in our QA chat: https://web.libera.chat/?settings=#libreoffice-qa

Thank you for helping us make LibreOffice even better for everyone!

Warm Regards,
QA Team

MassPing-UntouchedBug