Bug 171335 - Table rows cannot be pasted onto other rows unless their cells are matching
Summary: Table rows cannot be pasted onto other rows unless their cells are matching
Status: RESOLVED DUPLICATE of bug 98440
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
25.8.4.2 release
Hardware: All All
: medium normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords:
Depends on:
Blocks: Writer-Tables
  Show dependency treegraph
 
Reported: 2026-03-16 05:55 UTC by Danat
Modified: 2026-03-16 11:39 UTC (History)
5 users (show)

See Also:
Crash report or crash signature:


Attachments
Table row pasting irregularity (7.27 MB, video/mp4)
2026-03-16 05:55 UTC, Danat
Details
File in the video (10.35 KB, application/vnd.openxmlformats-officedocument.wordprocessingml.document)
2026-03-16 05:56 UTC, Danat
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Danat 2026-03-16 05:55:01 UTC
Description:
https://drive.google.com/file/d/1hFWRZHEHLKAcGQhhkUNjj5ThJxgiWGmE/view?usp=sharing

Steps to Reproduce:
1.Open the file
2.Select the last row of the second table
3.Copy it
4.Select the row above the last row of the second table
5.Paste the copied row

Actual Results:
It does not paste normally unless you merge the first 2 cells of the row above the last row of the second table

Expected Results:
Normal pasting


Reproducible: Always


User Profile Reset: No

Additional Info:
In the video
Comment 1 Danat 2026-03-16 05:55:31 UTC
Created attachment 206187 [details]
Table row pasting irregularity
Comment 2 Danat 2026-03-16 05:56:10 UTC
Created attachment 206188 [details]
File in the video
Comment 3 Eyal Rozenberg 2026-03-16 09:59:22 UTC
(In reply to Danat from comment #0)
> Actual Results:
> It does not paste normally unless you merge the first 2 cells of the row
> above the last row of the second table

You're not describing the actual result here. You're saying the actual result is not the result you'd expect.

> Expected Results:
> Normal pasting

And again, you're not saying what you're expecting.

At any rate, I would consider the pasting behabvior unacceptable, because, on one hand, Writer doess agree to paste, and on the other hand, it duplicates the contents of the first of the two copied cells, in the third cell. That is almost certainly not what the user expected or wanted.

Possibly acceptable pasting behavior in this case would be one of the following, IMO:

1. Paste the two cells onto the first two cells of the selected range, do not change the third cell.
2. Paste the two cells onto the first two cells of the selected range, clear the rest of the range (as though each cell had been selected and Delete was pressed).
3. Refuse to paste due to the incompatible range sizes (problematic, but avoids undesirable action)
4. Merge the first two cells in the target range, copy the two cell contents into the corresponding final two cells.
5. Open a dialog asking what to do.
Comment 4 Eyal Rozenberg 2026-03-16 10:07:22 UTC
It's important to search for duplicates. This is a bug about tables in writer, so searching the Writer-Tables dependency tree is appropriate.

Danat, note that if you're not sure which meta-bugs are relevant to a bug you're reporting, you can search the meta-bugs dynamically here:

https://wiki.documentfoundation.org/Meta_bugs

... and now I have to get to the bomb shelter.

*** This bug has been marked as a duplicate of bug 98440 ***
Comment 5 Danat 2026-03-16 10:29:28 UTC
(In reply to Eyal Rozenberg from comment #3)
> (In reply to Danat from comment #0)
> > Actual Results:
> > It does not paste normally unless you merge the first 2 cells of the row
> > above the last row of the second table
> 
> You're not describing the actual result here. You're saying the actual
> result is not the result you'd expect.
> 
> > Expected Results:
> > Normal pasting
> 
> And again, you're not saying what you're expecting.
> 
> At any rate, I would consider the pasting behabvior unacceptable, because,
> on one hand, Writer doess agree to paste, and on the other hand, it
> duplicates the contents of the first of the two copied cells, in the third
> cell. That is almost certainly not what the user expected or wanted.
> 
> Possibly acceptable pasting behavior in this case would be one of the
> following, IMO:
> 
> 1. Paste the two cells onto the first two cells of the selected range, do
> not change the third cell.
> 2. Paste the two cells onto the first two cells of the selected range, clear
> the rest of the range (as though each cell had been selected and Delete was
> pressed).
> 3. Refuse to paste due to the incompatible range sizes (problematic, but
> avoids undesirable action)
> 4. Merge the first two cells in the target range, copy the two cell contents
> into the corresponding final two cells.
> 5. Open a dialog asking what to do.

2 and 4 are fine if I do not imagine them wrongly

I want the pasted material to look exactly like the copied material. Any deviation would be unacceptable. It's by definition not copying if what you paste looks not like what copy