https://bugs.documentfoundation.org/show_bug.cgi?id=157417
Bug ID: 157417
Summary: A table becomes write protected without the user
choosing to set write protection.
Product: LibreOffice
Version: 7.6.1.2 release
Hardware: All
OS: Windows (All)
Status: UNCONFIRMED
Severity: normal
Priority: medium
Component: Writer
Assignee: libreoffice-bugs@lists.freedesktop.org
Reporter: hicijew...@bookspre.com
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
--
You are receiving this mail because:
You are the assignee for the bug.
