Description: Adding a row to a table does not format correctly Steps to Reproduce: 1.add a table 2.change internal formatting : colour 3.add row after last row (tab from bottom right hand cell) Actual Results: formatting not as expected Expected Results: the bottom border of what is now the second last row should have been changed (since it is now inside the table, and no longer the last row and the bottom border is now no longer the table outer border Does the same in LO 6.4 My work around has been to never use the last row, but to insert a row above it, not below it. Reproducible: Always User Profile Reset: No Additional Info: [Information automatically included from LibreOffice] Locale: en-GB Module: TextDocument [Information guessed from browser] OS: Linux (All) OS is 64bit: yes
Created attachment 174717 [details] after table create
Created attachment 174718 [details] borders of internal rows/columns colour change
Created attachment 174719 [details] row added after last row Note that the column added to the right hand side border is as expected, but the column added to the left hand side is not
*** Bug 142977 has been marked as a duplicate of this bug. ***
Seen on Windows as well and already in 3.3.0. Surprisingly, I could not find an earlier report. Version: 7.3.0.0.alpha0+ (x64) / LibreOffice Community Build ID: a866d63e0ac9de4ff7e59b3928f09ec21877bef3 CPU threads: 2; OS: Windows 10.0 Build 19042; UI render: Skia/Raster; VCL: win Locale: fi-FI (fi_FI); UI: en-US Calc: threaded Jumbo
Dear Elmar, 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
Created attachment 190883 [details] sample ODT with two different cases: table formated entirely vs partially Reproduced in: Version: 24.2.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: 5fe2bf914c251009ec4709fa8fdc45c3b53f676b CPU threads: 8; OS: Linux 5.15; UI render: default; VCL: gtk3 Locale: en-AU (en_AU.UTF-8); UI: en-US Calc: threaded Note in the attachment that the behaviour differs depending on if the whole table was formatted with inner/outer borders, or if they were only applied to a part of it.