Bug 133870 - Page wrap and anchoring changes copy/paste using Windows clipboard (since 6.4)
Summary: Page wrap and anchoring changes copy/paste using Windows clipboard (since 6.4)
Status: RESOLVED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
6.4.0.0.beta1+
Hardware: All Windows (All)
: lowest minor
Assignee: Not Assigned
URL:
Whiteboard: target:24.2.0 target:7.6.3
Keywords: bibisected, bisected, regression
Depends on:
Blocks: Anchor-and-Text-Wrap Clipboard
  Show dependency treegraph
 
Reported: 2020-06-10 17:28 UTC by Telesto
Modified: 2023-10-12 03:55 UTC (History)
3 users (show)

See Also:
Crash report or crash signature:


Attachments
Bibisect log (3.20 KB, text/plain)
2020-06-10 17:29 UTC, Telesto
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Telesto 2020-06-10 17:28:39 UTC
Description:
Page wrap and anchoring changes copy/paste using Windows clipboard

Steps to Reproduce:
1. Open attachment 160618 [details]
2. CTRL+A
3. CTRL+C
4. CTRL+Q
5. Launch Writer
6. CTRL+V -> Wrap isn't honored.. shape above text

Likely Windows only

Actual Results:
Wrap isn't honored.. shape above text

Expected Results:
Should look the same as when copied


Reproducible: Always


User Profile Reset: No



Additional Info:
Found in
Version: 7.1.0.0.alpha0+ (x64)
Build ID: 59939d2490726336546c7ad05082d23031074e12
CPU threads: 4; OS: Windows 6.3 Build 9600; UI render: Skia/Raster; VCL: win
Locale: nl-NL (nl_NL); UI: en-US
Calc: CL

and in
6.4
Comment 1 Telesto 2020-06-10 17:29:47 UTC
Created attachment 161851 [details]
Bibisect log

Bisected to
author	Jan Holesovsky <kendy@collabora.com>	2019-09-26 13:35:55 +0200
committer	Jan Holesovsky <kendy@collabora.com>	2019-09-27 09:54:06 +0200
commit e9e6d4b058e13165f3dde1ca7822eec97dfe8aa7 (patch)
tree dea7babee79d1acbf34ab8e81fed5aa355cf060b
parent ffa97dfc53ef902fe478f264c51989bd4c4434d1 (diff)
tdf#116685: Make the RICHTEXT take precedence over EMBED_SOURCE.
Before this patch, copy in Calc, Paste in Writer produced an embedded
sheet.  I suspect is it not what the people usually want; working with
the embedded sheets in Writer is non-intuitive, I suspect people will be
happier with a normal table which they can style etc. appropriately.

OTOH - this is a general change, so it might have some unwanted
side-effects; let's see what if we get bugreports :-)

tdf#127673 was related; but in my view, we shouldn't create the embedded
objects in the first place.

https://cgit.freedesktop.org/libreoffice/core/commit/?id=e9e6d4b058e13165f3dde1ca7822eec97dfe8aa7
Comment 2 Telesto 2020-06-10 17:35:21 UTC Comment hidden (no-value)
Comment 3 Telesto 2020-06-10 17:37:22 UTC Comment hidden (no-value)
Comment 4 Aron Budea 2021-11-08 00:48:59 UTC
Interestingly regular RTF paste doesn't even copy the shape.
Comment 5 Mike Kaganski 2023-10-10 06:50:09 UTC
(In reply to Telesto from comment #1)
> Bisected to
> commit e9e6d4b058e13165f3dde1ca7822eec97dfe8aa7 (patch)
> tdf#116685: Make the RICHTEXT take precedence over EMBED_SOURCE.

So it is the change that made RTF paste preferred; before that, the sequence from STR preferred Star Embed Source (XML). Pasting RTF had the same problem before the patch. Pasting Star Embed Source (XML) still works. Likely some additional analysis is needed to decide.

(In reply to Aron Budea from comment #4)
> Interestingly regular RTF paste doesn't even copy the shape.

I suppose that you confused RTF paste (which does copy the shape), and HTML (that doesn't).
Comment 6 Aron Budea 2023-10-10 07:30:15 UTC
(In reply to Mike Kaganski from comment #5)
> (In reply to Aron Budea from comment #4)
> > Interestingly regular RTF paste doesn't even copy the shape.
> 
> I suppose that you confused RTF paste (which does copy the shape), and HTML
> (that doesn't).
No, RTF paste doesn't paste the shape for me.
Comment 7 Mike Kaganski 2023-10-10 10:28:10 UTC
Commit 8ad0c29f56e5069a3679560d404b603332dcf38a dealt with a similar case - except for step 4 in the original STR.

In SwTransferable::SelectPasteFormat, that was introduced there, the check for TransferableObjectDescriptor's class name would only succeed when the descriptor was created in this instance of the program. It is not read from the clipboard, so not populated when the paste comes from another instance.

It is of lowest possible priority - because it's absolutely artificial case to change the instances on the same system between a copy and a paste. But the fix would be to read the data from the clipboard there.
Comment 8 Commit Notification 2023-10-11 04:14:38 UTC
Mike Kaganski committed a patch related to this issue.
It has been pushed to "master":

https://git.libreoffice.org/core/commit/3191b322b59cab22ec4c67c0d83520ff577f7ae8

tdf#133870: read OBJECTDESCRIPTOR from clipboard

It will be available in 24.2.0.

The patch should be included in the daily builds available at
https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
https://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.
Comment 9 Commit Notification 2023-10-11 09:19:26 UTC
Mike Kaganski committed a patch related to this issue.
It has been pushed to "libreoffice-7-6":

https://git.libreoffice.org/core/commit/b651051fce541ef5f8375154889922488189a4be

tdf#133870: read OBJECTDESCRIPTOR from clipboard

It will be available in 7.6.3.

The patch should be included in the daily builds available at
https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
https://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.