Bug 167943 - Pasting paragraph with local formatting is affected by format of previous paragraph
Summary: Pasting paragraph with local formatting is affected by format of previous par...
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
25.2.0.0 alpha0+
Hardware: All Linux (All)
: medium normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords: bibisected, bisected, regression
Depends on:
Blocks: Paste
  Show dependency treegraph
 
Reported: 2025-08-13 18:55 UTC by Jim Avera
Modified: 2025-09-08 18:38 UTC (History)
3 users (show)

See Also:
Crash report or crash signature:


Attachments
psdemo.odt (see Steps to Reproduce) (18.89 KB, application/vnd.oasis.opendocument.text)
2025-08-13 18:57 UTC, Jim Avera
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Jim Avera 2025-08-13 18:55:31 UTC
Description:
If a paragraph is copy-pasted, the formatting is changed (i.e. not exactly reproduced) in the destination depending on the format of the existing paragraph where the content is pasted into.

In particular, copied content can not be reliably pasted a second time after pressing "return" the first time (to start another paragraph) because the previously-pasted paragraph has a "Next paragraph" style which somehow modifies the format of the paste content.

This might be just a documentation issue (i.e. may or may not be code misbehavior).  However it seems counter-intuitive to me.   When content is pasted, are the original styles copied and used, or is all the formatting converted into local override formatting (anonymous styles)?

The docs on copy/paste are silent about this.  To my eyes this implies that copy-paste should make the pasted content use all the same para and char styles that the original uses (copying the needed styles to the new document if pasting into another document).

https://help.libreoffice.org/latest/en-US/text/swriter/guide/dragdroptext.html

Please open the attached demo document, select ALL and paste into the new document.  Press RETURN to start a new paragraph, then paste again.  Every other copy is corrupted.

Steps to Reproduce:
1. Open attached "psdemo.odt".  View->Formatting Marks checked.
2. File->New->Text Document (reposition the new window so you can see both)
3. Click in the original document.  Control-A to select all.
4. Click in the new, empty doc.  Control-V to paste
5. Press RETURN (creates a new paragraph)
6. Control-V to paste

Actual Results:
The second paste does not reproduce the formatting correctly

Expected Results:
(I was assuming that pasting an entire paragraph would insert a new paragraph with exactly the same formatting)


Reproducible: Always


User Profile Reset: No

Additional Info:
If this is expected behavior, it would be helpful to explain in the docs what is happening in the docs e.g. at https://help.libreoffice.org/latest/en-US/text/swriter/guide/dragdroptext.html

It should specifically say how to paste a paragraph (or multiple paras) into an arbitrary location and get exactly the same formatting as the original regardless of how surrounding paragraphs are formatted.
Comment 1 Jim Avera 2025-08-13 18:57:15 UTC
Created attachment 202316 [details]
psdemo.odt (see Steps to Reproduce)
Comment 2 Jim Avera 2025-08-13 18:59:21 UTC
Repeating steps 4 & 6 over and over alternately creates "correct" and "corrupted" paragraphs.
Comment 3 Jim Avera 2025-08-13 19:02:42 UTC
Sorry, it is not necessary to paste into a new document to demo the behavior; you can just Control-A in the original doc, press return to create a new paragraph there, and Control-V to paste there (the copy is ruined).
Comment 4 Takenori Yasuda 2025-08-14 03:58:42 UTC
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.1.0.0+ (X86_64) / LibreOffice Community
Build ID: b75c382be45616a29ffc67cec47d8772e86a74b7
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


Not reproduced:
Version: 24.8.7.2 (x86) / LibreOffice Community
Build ID: e07d0a63a46349d29051da79b1fde8160bab2a89
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
Comment 5 BogdanB 2025-08-14 08:38:30 UTC
Confirmed, based on comment 4.
Comment 6 raal 2025-08-14 16:35:55 UTC
This seems to have begun at the below commit in bibisect repository/OS linux-64-25.2.
Adding Cc: to Michael Stahl ; Could you possibly take a look at this one?
Thanks
 7b02f0b39f76a7e6eec77b531ff227a0ae3ebc74 is the first bad commit
commit 7b02f0b39f76a7e6eec77b531ff227a0ae3ebc74
Author: Jenkins Build User <tdf@maggie.tdf>
Date:   Fri Aug 9 12:02:46 2024 +0200

    source e14fc683536ec2926c70ea94dfd7a549a9bc1460

171644: sw: fix SwTextNode::MoveTextAttr_To_AttrSet() | https://gerrit.libreoffice.org/c/core/+/171644