Bug 166882 - ODF clipboard: Cannot copy/paste graphic bullet via the clipboard
Summary: ODF clipboard: Cannot copy/paste graphic bullet via the clipboard
Status: RESOLVED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Impress (show other bugs)
Version:
(earliest affected)
Inherited From OOo
Hardware: All All
: medium normal
Assignee: Balázs Varga
URL:
Whiteboard: target:26.2.0
Keywords: bibisected, bisected
Depends on:
Blocks:
 
Reported: 2025-06-06 14:42 UTC by Balázs Varga
Modified: 2025-07-30 16:30 UTC (History)
2 users (show)

See Also:
Crash report or crash signature:


Attachments
Example document (15.79 KB, application/vnd.oasis.opendocument.presentation)
2025-06-06 14:44 UTC, Balázs Varga
Details
Screenshot after copy-paste of the second paragraph (101.53 KB, image/png)
2025-06-06 14:45 UTC, Balázs Varga
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Balázs Varga 2025-06-06 14:42:56 UTC
Description:
Graphical bullet point is missing after copy-paste.

Steps to Reproduce:
1.Open attached document.
2.Select the second paragraph in the textbox and copy it.
3.Go to the end of the second paragraph hit enter and a new empty paragraph will be created with a (graphic) bullet.
4.Paste the originally copied second paragraph into the third paragraph.

Actual Results:
The (graphic) bullet disappeared.

Expected Results:
The (graphic) bullet should not disappeared.


Reproducible: Always


User Profile Reset: No

Additional Info:
Reproduced in:
Version: 25.2.3.2 (X86_64) / LibreOffice Community
Build ID: bbb074479178df812d175f709636b368952c2ce3
CPU threads: 20; OS: Windows 11 X86_64 (10.0 build 26100); UI render: Skia/Raster; VCL: win
Locale: hu-HU (hu_HU); UI: en-US
Calc: CL threaded

Not reproducible in:
Version: 24.8.6.2 (X86_64) / LibreOffice Community
Build ID: 6d98ba145e9a8a39fc57bcc76981d1fb1316c60c
CPU threads: 8; OS: Windows 11 X86_64 (10.0 build 26100); UI render: Skia/Raster; VCL: win
Locale: hu-HU (hu_HU); UI: en-US
Calc: threaded

Regression from commit: 0d3748e5fbfb2ac8dd60d491d566075938927237
(tdf#163598 editeng: avoid using fake outline depth)
Comment 1 Balázs Varga 2025-06-06 14:44:38 UTC
Created attachment 201121 [details]
Example document
Comment 2 Balázs Varga 2025-06-06 14:45:50 UTC
Created attachment 201122 [details]
Screenshot after copy-paste of the second paragraph
Comment 3 Andrew Kopf 2025-06-06 17:58:18 UTC
Hello Balázs Varga,

Thank you for reporting the bug. I can confirm that the bug is present in master.

Version: 25.8.0.0.alpha1+ (X86_64) / LibreOffice Community
Build ID: 19f3b72f34c487dc97d582712d21734a7e055fd5
CPU threads: 22; OS: Windows 11 X86_64 (build 26100); UI render: Skia/Raster; VCL: win
Locale: en-US (en_US); UI: en-US
Calc: CL threaded
Comment 4 Justin L 2025-07-02 14:03:15 UTC
These steps-to-reproduce with example.odp did not work in 7.4. (They worked in 5.3, 6.4, but stopped working in 7.0.)

7.0 commit 66ed51712bb323bba7d1a0b0d21b256e5f5f9ccf
Author: Katarina Behrens on Fri Jan 17 14:30:56 2020 +0100
    tdf#128046: preserve list levels on paste
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/86983

The steps-to-reproduce started working again in my first commit of this mess:
7.5 commit f7b5eefc36f6a7627e867651bafe38bdeb2f9c00
Author: Justin Luth on Thu Jul 28 09:03:13 2022 -0400
    tdf#148810 pptx import: Depth set by EE_PARA_OUTLLEVEL

As soon as you start to include multiple paragraphs/levels then things get interesting...
Comment 5 Justin L 2025-07-02 21:45:22 UTC
So, by mangling the code I can "fix" this by:
1.) disabling part of Katarina's change
+//   { UNO_NAME_NUMBERING_RULES,        EE_PARA_NUMBULLET,  cppu::UnoType<css::container::XIndexReplace>::get(), 0, 0 },

or 2.) providing a depth of -1 (by not returning false/true) with getPropertyValue - at which point XMLTextNumRuleInfo::Set receives an empty aAny which fails to set any mnListLevel, which prevents any attempt to populate mxNumRules - getting the same effect as #1 - no export of the list rule.

When the example document is using "Bullets", then everything works, but this example is using a "Graphic". It only "worked" because no numbering rule information was being copied across - therefore it didn't overwrite the paragraphs existing numbering rule. So it only seems to work "accidentally". I.E. it effectually is only copy/pasting text before - not numbering, so if you were pasting into a totally different numbering list you wouldn't get a checkmark.

I'm assuming that ultimately the problem is that the clipboard doesn't get a copy of the bitmap.

Yeah. SvXMLExport::AddEmbeddedXGraphic doesn't have an mxGraphicStorageHandler, so it doesn't create an sURL, and thus we get an empty
 OUString sInternalURL = GetExport().AddEmbeddedXGraphic(xGraphic, sUsedMimeType)
and so no xlink:href is exported in SvxXMLNumRuleExport::exportLevelStyle. 

The import path for the exported clipboard ODF is xmloff/source/style/xmlnumi.cxx
Comment 6 Commit Notification 2025-07-30 16:19:34 UTC
Balazs Varga committed a patch related to this issue.
It has been pushed to "master":

https://git.libreoffice.org/core/commit/006c8f2d7517965657a9caca1fa7afd757f2f4c5

tdf#166882 - sd odf clipboard: fix missing copy/pasted graphic bullets

It will be available in 26.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.