Description:
This bug appeared while I was working in an ODT document with multiple separate tables. When attempting to move tables around by copying and pasting, the original table could not be deleted. Cell contents and unmerged rows or columns could be deleted without issue. Merged cells could also be deleted freely prior to setting the table properties to exclude breaking rows across pages, but no indication was given at any time that this setting would result in the entire table being treated as write protected simply due to a merged cell being present. This outcome seems unintentional, and is undesirable without any form of communication that it happened because of that setting.



Steps to Reproduce:
How to reproduce in OL Writer:
1. Create a new OL Writer ODT file.
2. Make a 2x2 table. Default settings.
3. Select 1 column. Merge the 2 cells together.
4. Select entire table. Go to Table Properties > Text Flow.
5. Uncheck 'Allow row to break across pages and columns' and click OK.

Actual Results:
With the entire table selected, 
- the table cannot be deleted, whether by the Delete key or by context menu.
- using the Delete key will give an error message indicating that the table is write protected.
- the Write Protection options in the table menu show as disabled (greyed out).

With individual cells selected
- none show as having Write Protection enabled (via Table menu).

With the column of merged cells selected,
- the column of merged cells cannot be deleted

With the column of unmerged cells selected,
- the column of unmerged cells can deleted and the single remaining merged cell can now be deleted.

Selecting rows, whether or not the merged cell is included, appears to be unaffected by this bug.

Adding additional rows or columns may or may not change the behaviour, depending on where they are added, how many, and in what order. For example, adding a single 3rd row to the bottom of the 2x2 table seems to remove the bug if no further modifications are made. However, the bug may reappear if further columns are added, such as repeating the merged cell. Repetitions of different varieties of these actions produces mixed results.

Expected Results:
The expected behaviour is that collections of 2 or more rows that share 1 or more merged cells should remain together as a group when determining if the given rows do or do not break across pages, in the same manner that a single row or cell with multiple lines of text may or may not break across a page depending on its size and location.

It is also expected that the user be able to delete such a table as desired, since no write protection was chosen.

This bug also seems to affect changing the size of the table (or rows and columns that include merged cells), but that seems secondary and perhaps more complex to resolve.


Reproducible: Always


User Profile Reset: Yes

Additional Info:
Version: 7.6.1.2 (X86_64) / LibreOffice Community
Build ID: f5defcebd022c5bc36bbb79be232cb6926d8f674
CPU threads: 20; OS: Windows 10.0 Build 19045; UI render: Skia/Raster; VCL: win
Locale: en-US (en_US); UI: en-US
Calc: threaded