| Summary: | FORMATTING - Column Insert does not always insert a New column | ||
|---|---|---|---|
| Product: | LibreOffice | Reporter: | Stang <whistler715> |
| Component: | Calc | Assignee: | Not Assigned <libreoffice-bugs> |
| Status: | NEW --- | ||
| Severity: | normal | CC: | buzea.bogdan, raal |
| Priority: | medium | ||
| Version: | 4.4.7.2 release | ||
| Hardware: | x86-64 (AMD64) | ||
| OS: | Linux (All) | ||
| Whiteboard: | |||
| Crash report or crash signature: | Regression By: | ||
| Bug Depends on: | |||
| Bug Blocks: | 108364 | ||
| Attachments: | Sample - Directions in text | ||
Also tested with Daily from 7/20/2017 - 6.0.0.0 x86-64 deb (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 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 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). 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 ** Please read this message in its entirety before responding ** 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 http://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://kiwiirc.com/nextclient/irc.freenode.net/#libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug 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://kiwiirc.com/nextclient/irc.freenode.net/#libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug 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 Please retest the bug. Don't repro with Version: 7.5.3.2 (X86_64) / LibreOffice Community Build ID: 9f56dff12ba03b9acd7730a5a481eea045e468f3 CPU threads: 16; OS: Linux 5.19; UI render: default; VCL: gtk3 Locale: ro-RO (ro_RO.UTF-8); UI: en-US Calc: threaded (In reply to BogdanB from comment #9) > Please retest the bug. Don't repro with > Version: 7.5.3.2 (X86_64) / LibreOffice Community > Build ID: 9f56dff12ba03b9acd7730a5a481eea045e468f3 > CPU threads: 16; OS: Linux 5.19; UI render: default; VCL: gtk3 > Locale: ro-RO (ro_RO.UTF-8); UI: en-US > Calc: threaded Which part? 1? 2? 3? BTW, column AMJ is no longer the last column. Setting back to New. Sorry. |
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.