Description: IF a user created a border around 4 or more cells (2 or more rows and 2 or more columns) and then merges the cells within the border, the right and lower /bottom border will disappear. If the user selects 2 or more cells within a column and adds a border and then Merges the cells the lower / bottom border will disappear. If the user selects 2 or more cells within a row and adds a border and then merges the cells, the right border will disappear The above behavior is the same using the menus , ribbon or right click>menu and combination of these. work around is to add the border after the cells are merged. Steps to Reproduce: 1. Open a new Calc sheet 2. Select 2 or more cells in a row and use 3. Add a border to the selected cells 4. Merge the selected cells Actual Results: If selected cells are in a row the right border will disappear If selected cells are in a column the bottom border with disappear If selected cells span both rows and columns the right and bottom border will disappear Expected Results: All borders should remain in tack and visible after the cell Merge Reproducible: Always User Profile Reset: No Additional Info: Version: 25.2.4.3 (X86_64) Build: 33e196637044ead23f5c3226c Environment: CPU Threads: 8 OS Windows 7 Service Pack 1 X86_64 (6.1 build 7601) User Interface: UI render: Skia/Raster; VCL:win Locale: en-US (en_US); UI: en-US Misc: Calc:threaded
I am not able to reproduce this bug in Version: 25.2.4.3 (X86_64) / LibreOffice Community Build ID: 33e196637044ead23f5c3226cde09b47731f7e27 CPU threads: 16; OS: Windows 11 X86_64 (10.0 build 26100); UI render: Skia/Vulkan; VCL: win Locale: en-US (de_DE); UI: en-US Calc: threaded
Reproduced. Version: 25.2.5.2 (X86_64) / LibreOffice Community Build ID: 03d19516eb2e1dd5d4ccd751a0d6f35f35e08022 CPU threads: 8; OS: Windows 11 X86_64 (10.0 build 26100); UI render: Skia/Raster; VCL: win Locale: ja-JP (ja_JP); UI: ja-JP Calc: CL threaded Jumbo Version: 25.8.0.1.0+ (X86_64) / LibreOffice Community Build ID: f1f1445bb25d48289e77ec5e06da9a57502fa119 CPU threads: 8; OS: Windows 11 X86_64 (build 26100); UI render: Skia/Raster; VCL: win Locale: ja-JP (ja_JP); UI: ja-JP Calc: CL threaded Jumbo I believe this bug is the same as Bug 155466. Could someone please check?
I retested after reading bug 154466 and was able to replicate the additional behavior mentioned in that bug as follows: It appears that the Merge Cells action is taking the formatting for the resulting merged cells borders from the top left cell (top cell if merged cells are in one column or the left most cell if merged cells are in a single row) before the Cell Merge So the resultant formatting is not disappearing but instead being taken from the top left cell and overwriting any existing formatting (appears to disappear if the top left cell does not have a right, left, top or bottom boarder. To replicate: 1. Open a new ODS 2. Select cells B2 : D3 3. Format cells B2: D3 to have single lines both inside and outside 4. Change the top border of cell B2 to be blank 5. Change the right border of cell B2 to be a double line 6. Change the bottom border of cell B2 to be a a long and short dashed line 7. Change the left border of cell B2 to be a dotted line 5. Select and Merge Cells B2:D3 6. The result will be: top border will be nothing, the right border will be a double line, the bottom boarder will be a long and short dashed line and the left boarder will be a dotted line. Note other lines/borders within the Merged Cell area appear to have no effect - only the borders of the top left cell (top cell if merged cells are in one column or the left most cell if merged cells are in a single row) have any effect. One exception or difference from bug 154466 I found in my testing was a difference in where the inheritance of the formatting comes from - I agree with original author but not with the following repeated comment: " ady 2023-06-24 00:31:36 UTC (In reply to Franklin Weng from comment #0) > Actual Results: > The right (and sometimes bottom also) border would disappear Right and bottom sides are the corresponding left and top sides of the adjacent surrounding cells. " I always found the resulting formatting to come from the matching side of the top left cell. I also found this same behavior if the cels are not empty for all three Content Merge options I could not find any predicted behavior for borders in the Calc documentation so am not sure if this behavior is by design or a bug. In testing an older Excel 2003 the end result with the same input steps was no top border (same result), no left border and single line right and bottom borders.(different result). I have modified the bug title to better reflect what is actually happening To me this bug is a duplicate of bug 154466 but it would be good if that author would confirm.