Bug 169061 - Pasting text into comment field adds line into comment that is not included in text
Summary: Pasting text into comment field adds line into comment that is not included i...
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Calc (show other bugs)
Version:
(earliest affected)
24.8.0.0 alpha0+
Hardware: All All
: medium normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords: bibisected, bisected
Depends on:
Blocks: Calc-Comments Paste
  Show dependency treegraph
 
Reported: 2025-10-25 15:47 UTC by BDF
Modified: 2026-01-31 17:23 UTC (History)
3 users (show)

See Also:
Crash report or crash signature:


Attachments
CALC - bug - copy text into comment (455.94 KB, video/webm)
2025-10-25 15:47 UTC, BDF
Details
CALC - bug 169061 - copy text into comment field - demo file (9.52 KB, application/vnd.oasis.opendocument.spreadsheet)
2026-01-31 13:09 UTC, BDF
Details

Note You need to log in before you can comment on or make changes to this bug.
Description BDF 2025-10-25 15:47:41 UTC
Created attachment 203541 [details]
CALC - bug - copy text into comment

***
If you're not sure this is actually a bug, instead post about it at https://discuss.kde.org

If you're reporting a crash, attach a backtrace with debug symbols; see https://community.kde.org/Guidelines_and_HOWTOs/Debugging/How_to_create_useful_crash_reports

Please remove this comment after reading and before submitting - thanks!
***

SUMMARY
When you copy text from another application into the comment field of calc, a new line is displayed, that does not exist in the comment

STEPS TO REPRODUCE
1. Add a comment to a cell
2. Copy text from a different application
3. Insert the text into the comment

OBSERVED RESULT
Even though the text itself does not seem to include any new line, the comment behaves as if there was one. Yet, it does not really exist as you can not 'delete' it. (So it's a sort of fake new line)

EXPECTED RESULT
Text is pasted without the new line

SOFTWARE/OS VERSIONS
LibreOffice Version:
Version: 25.8.2.2 (X86_64) / LibreOffice Community
Build ID: d401f2107ccab8f924a8e2df40f573aab7605b6f
CPU threads: 12; OS: Linux 6.14; UI render: default; VCL: gtk3
Locale: de-AT (de_AT.UTF-8); UI: de-DE
Flatpak
Calc: threaded

Used OS:
Operating System: KDE neon User Edition
KDE Plasma Version: 6.5.0
KDE Frameworks Version: 6.19.0
Qt Version: 6.9.2
Kernel Version: 6.14.0-33-generic (64-bit)
Graphics Platform: Wayland

Used browser to copy text:
Opera One (version: 122.0.5643.142)
Update stream:Stable
System:KDE neon User Edition (x86_64; KDE)
Chromium version:138.0.7204.251

ADDITIONAL INFORMATION
I noticed that this can not be triggered by any application. I used a web browser and Wikipedia. I know that titles on Wikipedia can include new lines. However 1) I have never seen this with regular text, only with titles 2) the new line is usually *after* the inserted text, not before and 3) I only get the new line when I double click the title, never when I select it with the mouse cursor.

Maybe this is related to html formatted text?
Comment 1 BDF 2025-10-25 22:13:00 UTC
More testing with different programs:
I tried to copy a random text as shown in the video. If the application caused the problem as well, it get a "YES", if not "NO".

- Audacity: NO
- Authenticator (Gnome): NO
+ Bookworm: YES
- Calculator (Gnome): NO
+ Chromium (on Wikipedia): YES
+ Discover (KDE): YES
+ Dolphin (KDE, file name): YES
- Emoji selector (single emoji icon): NO
+ Firefox: YES
- GIMP: NO
- gitg: NO
- GParted: NO
- Inkscape: NO
+ JOSM: YES
~ KGeoTag: YES (About section) & NO (drop down menu in main content area)
~ KWrite: NO (copy plain text from edit wind) & YES (copy text from the "About KDE" section)
~ OBS: NO (main content area) & YES (about section)
+ Steam (Valve): YES
+ System settings (KDE): YES
- Writer (LibreOffice, plain text): NO
Comment 2 BogdanB 2025-10-26 19:37:30 UTC
What I noticed is that after the text that is pasted all the new lines that will be inserted will have an emptry line. So after each Enter, we will have an empty line, then the new line, and so on...
Comment 3 Buovjaga 2026-01-29 16:51:02 UTC
Bibisected with linux-64-24.8, copying file name from Dolphin. The first change was that nothing was pasted, this began with commit ce53519f025158f8f64a4e8603c8c6e0dc35473a
cool#8023 editeng: support HTML paste

The current state began with 0503f6718f7686f3e2c93fc13af23e9fbfdace42
tdf#159507 editeng: support pasting HTML fragments

Let's ask Miklós what he thinks.
Comment 4 Miklos Vajna 2026-01-30 09:01:00 UTC
Care to share the Calc document you used to produce that demo video?

In general, when you paste, now we take the HTML content of the clipboard into account, so for example if your selection had a hyperlink, we no longer lose it in paste. As a side effect of this, it may be now more visible if the existing editeng HTML import does something unexpected with newlines.

Note that the start and end of pasted content is always tricky, since you can paste in the middle of an existing paragraph and the clipboard content is a self-contained document, so it's always a question if the starting and ending paragraph of that should be put into an existing paragraph or a new one.

Example: if your clipboard content starts with a heading and your cursor is at the end of an existing paragraph, you probably do want a paragraph break between the cursor position and the start of the pasted content. But if you just copy a single word, then you probably don't.

So this sounds like a pre-existing problem (how editeng HTML import behaves, which is now used for calc cell text and comment text), but if we know more about the target document and the pasted HTML (a clipboard dump would be ideal), then possibly things can be improved.
Comment 5 Buovjaga 2026-01-30 10:07:58 UTC
(In reply to Miklos Vajna from comment #4)
> So this sounds like a pre-existing problem (how editeng HTML import behaves,
> which is now used for calc cell text and comment text), but if we know more
> about the target document and the pasted HTML (a clipboard dump would be
> ideal), then possibly things can be improved.

Oh, now I thought to see what CopyQ displays and indeed, copying a file name from Dolphin comes with a relatively huge amount of HTML:

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0//EN" "http://www.w3.org/TR/REC-html40/strict.dtd">
<html><head><meta name="qrichtext" content="1" /><meta charset="utf-8" /><style type="text/css">
p, li { white-space: pre-wrap; }
hr { height: 1px; border-width: 0; }
li.unchecked::marker { content: "\2610"; }
li.checked::marker { content: "\2612"; }
</style></head><body>
<p style=" margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px;"><!--StartFragment-->numbers-bidi.docx<!--EndFragment--></p></body></html>

Probably this might even be unintentional on the part of Dolphin devs, but convenient for us to test with.
Comment 6 BDF 2026-01-31 13:09:19 UTC
Created attachment 205292 [details]
CALC - bug 169061 - copy text into comment field - demo file

(In reply to Miklos Vajna from comment #4)
> Care to share the Calc document you used to produce that demo video?
> 

I do not have this old file any more, but I recreated it.

-> Cell D10: Cell with comment *before* it was filled with a text copied from a different source. ("not pasted >")

-> Cell D12: Cell with comment after the text from a different source was pasted. ("pasted >").

I copied the part "celebrating its 25th birthday" from the part "The English-language Wikipedia is celebrating its 25th birthday! Learn how you can take part in the encyclopedia's continued improvement." at the very top of https://en.wikipedia.org/wiki/Main_Page


The steps for cell D10 are as described:
1) copy text from a different source
2) insert the text into the comment (Ctrl + V)