When a source cell without comment is copied whith Ctrl-C and pasted to a target cell with Ctrl-V, an existing comment of the target cell does not disappear although it should. Function Edit/Insert Contents/Insert Contents/ALL=Yes shows same fault. This wrong behaviour was seen since version 7.6. actual System: Windows 10 x64, LibreOffice 24.2.3.2
Confirm with Version: 24.8.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: 6d5d9eaa61505cebaf3bde4bfc157d8e19fec8de CPU threads: 4; OS: Linux 6.5; UI render: default; VCL: gtk3 Locale: cs-CZ (cs_CZ.UTF-8); UI: en-US Calc: threaded Jumbo Work in 7.3.3
This seems to have begun at the below commit in bibisect repository/OS linux-64-7.6. Adding Cc: to Andreas Heinisch ; Could you possibly take a look at this one? Thanks ca3d029dd18bba9118dce4bd591721002b7b4a4e is the first bad commit commit ca3d029dd18bba9118dce4bd591721002b7b4a4e Author: Jenkins Build User <tdf@pollux.tdf> Date: Sun Oct 29 06:16:11 2023 +0100 source 535f8fde0c33c435e4a8e9f768003516ce933666 151759: tdf#141440 - Do not delete notes when pasting contents | https://gerrit.libreoffice.org/c/core/+/151759
In bug 141440 this functionality was requested and implemented. I understand both workflows. Any thoughts?
(In reply to Andreas Heinisch from comment #3) > In bug 141440 this functionality was requested and implemented. I understand > both workflows. Any thoughts? The request in tdf#141440 is about paste special, without having the comments/notes selected as part of the paste action. I understand the confusion. The intention (IIUC) in tdf#141440 is that if you paste, say, _only_ the content of the cell, the other factors should not be altered on the destination cell/range (e.g. the cell format remains, and also the comments/notes and everything other than the cell content in this example). But when you paste all, or paste special when the checkbox for the comments is marked ON in the dialog, the comments are also replaced by the paste action, according to the original source cell/range. If the original cell/range contains a comment, it should end up pasted on the destination cell/range too in such case.
(In reply to ady from comment #4) > But when you paste all, or paste special when the checkbox for the comments > is marked ON in the dialog, the comments are also replaced by the paste That should had been: "...the comments should also be replaced by the paste..." because ATM they aren't (that's the bug), but they _should_ under these conditions.
I can confirm that an existing note gets replaced correctly when copied cell contains an note. The bug is only when source cell has not any note/comment.
(In reply to Roland from comment #6) > I can confirm that an existing note gets replaced correctly when copied cell > contains an note. The bug is only when source cell has not any note/comment. I have modified the Summary accordingly. I can see the potential advantage for some use-cases for such behavior. The problem is the inconsistency regarding pasting other factors. I mean that someone might request that when a cell value is empty, then the copy+paste should skip the empty value replacing whichever non-empty value occupies the destination cell. Or some similar oddity with some other property (e.g. no borders in the source cell). The current alternative is that users have to explicitly delete the comment of the target cell after pasting. I guess that UX has to opine on this one (independently of the original request in tdf#141440)?
To be clear, in any case the request from tdf#141440 should be canceled. The request in that report was and still is valid. When pasting _only_ values, then the other factors should not be affected in the target cell. The potential confusion in tdf#141440 (which triggered this new report tdf#161189) comes from those paste special quick shortcuts and/or accelerators/icons/menus such as "paste text" or "paste formulas" or "paste numbers", which could mean either: * paste all, but only when the source cells contain "text/formulas/numbers" (respectively); or, * paste values only, but only when the source cells contain "text/formulas/numbers" (respectively).
Oops. Sorry: (In reply to ady from comment #8) > To be clear, in any case the request from tdf#141440 should be canceled. To be clear, in any case the request from tdf#141440 should **NOT** be canceled.
(In reply to ady from comment #7) > I guess that UX has to opine on this one Andreas is assigned to fix the issue, so he prolly has a plan. Or will ask questions...