Bug 131438 - An image that once was an area fill persists in the file even if it is deleted from the collection (comment 7)
Summary: An image that once was an area fill persists in the file even if it is delete...
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
5.3.0.3 release
Hardware: All All
: medium normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords: implementationError
: 151177 (view as bug list)
Depends on:
Blocks: Area-Fill-Tab-Image
  Show dependency treegraph
 
Reported: 2020-03-20 10:21 UTC by Mike Kaganski
Modified: 2023-10-01 20:44 UTC (History)
3 users (show)

See Also:
Crash report or crash signature:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Mike Kaganski 2020-03-20 10:21:07 UTC
1. Create a new text document;
2. Format page style to have a custom bitmap as the area fill (use Add/Import in the Page Style dialog on tab Area in Bitmap mode) - make sure to apply;
3. Edit the page style again to remove the fill (set it to None) - this can be even done without closing the dialog at step 2, just after Apply button pressed;
4. Save the file, and inspect its contents using ZIP.

The bitmap is inside the document, referenced from styles.xml's draw:fill-image element. There's no way to remove it; after reloading the document, the image is absent in the gallery on the Bitmap page of Area tab, thus one cannot delete it.

Seems there was never a way to remove it; although the Area page changed over time, I couldn't quickly find a version where it allowed to remove the image from the document file. Tested with:

Version: 6.4.2.2 (x64)
Build ID: 4e471d8c02c9c90f512f7f9ead8875b57fcb1ec3
CPU threads: 12; OS: Windows 10.0 Build 18363; UI render: default; VCL: win; 
Locale: ru-RU (ru_RU); UI-Language: en-US
Calc: CL

Version: 7.0.0.0.alpha0+ (x64)
Build ID: b29fb89d0a49fde0f5757774d64a7aba8298ac75
CPU threads: 12; OS: Windows 10.0 Build 18363; UI render: Skia/Raster; VCL: win; 
Locale: ru-RU (ru_RU); UI-Language: en-US
Calc: CL

Version: 5.0.4.1 (x64)
Build ID: 2def61bcbb29a7a8611b833682fe1291910b11ad
Locale: ru-RU (ru_RU)

and OpenOffice.org 3.2.0 OOO320m12 (Build:9483).
Comment 1 Dieter 2020-03-25 18:19:02 UTC
I confirm it with

Version: 7.0.0.0.alpha0+ (x64)
Build ID: 5dcbd1bb557450a2d658a710c163b310c0cee157
CPU threads: 4; OS: Windows 10.0 Build 18363; UI render: Skia/Raster; VCL: win; 
Locale: de-DE (de_DE); UI-Language: en-GB
Calc: CL
Comment 2 R. Green 2020-03-29 16:27:44 UTC
Version: 6.4.1.2 (x64)
Build ID: 4d224e95b98b138af42a64d84056446d09082932
CPU threads: 4; OS: Windows 10.0 Build 18363; UI render: default; VCL: win; 
Locale: en-GB (en_GB); UI-Language: en-GB
Calc: threaded

Confirmed with this version.

1. Create the default writer document.
2. Go to "Page Style (Default) > Area". Press "Bitmap", then press "Add/Import" and import a background image. Save it using the default dialogue box that pops up. Then press "Apply."

EXPECTED RESULT: Icon should be accessible under "Bitmap" using the scrollbar.
ACTUAL RESULT: Icon is not accessible.

3. Close dialogue and reopen.

RESULT: The imported background is accessible again via scrollbar.

4. Close dialogue. Save, close then reopen file; then open dialogue again.

RESULT: Background is inaccessible, and remains so permananetly. The same goes for any other backgrounds you import.
Comment 3 Dieter 2020-03-30 10:04:27 UTC
R. Green, you've changed bug summary, and AFAIK the expected result is now a bit different.

Problem: Image is still part of the program, but you don't have access to it.

Expected result in comment 0: LO should remove image from the program
Expected result in comment 2: LO should make bitmap accessable for later use

There should be a consensus about the expeted result. From a user perspective I tend to your expectation, R. Green.

Mike, what do you think? Or have I misunderstood something?
Comment 4 Mike Kaganski 2020-03-30 10:18:07 UTC
(In reply to Dieter from comment #3)

Well, comment 0 didn't declare that image should become removed automatically: strictly speaking, I only wrote that there's no way to remove it. Comment 2 indeed suggests the most obvious (and likely the only correct) way of solving the bug, so I also tend to agree with the edits :-) - however, the automatic removal of unreferenced images is also an option (inferior IMO).
Comment 5 Heiko Tietze 2020-12-07 10:47:33 UTC
Duplicate of bug 125969?
Comment 6 Mike Kaganski 2022-09-26 07:23:06 UTC
*** Bug 151177 has been marked as a duplicate of this bug. ***
Comment 7 Stéphane Guillou (stragu) 2023-10-01 20:44:31 UTC
I am reverting back to something similar to the original summary by Mike.
The Comment 2 issue is more what's tracked in bug 125969, whereas this issue I think is best described with the steps below. Admittedly, both issues should be fixed in concert, but they are two different problems.

1. In a new file: Format > Page Style > Area > Image > Ass / Import an image, give it a name
2. Apply the image as background without closing the dialog
3. Change image background to one of the defaults, click Apply
4. Right-click the custom image in the collection, delete it
5. Save file and exit LO
6. Extract the ODT, look in Pictures directory

Result: custom image is still there. Which in a way touches on the issue of privacy.

Setting first version affected as 5.3 as that's when one could first add a custom image to the collection and use that "Delete" context menu command.

Still reproduced in recent trunk build:

Version: 24.2.0.0.alpha0+ (X86_64) / LibreOffice Community
Build ID: e9a0c97de95688b2f86bbb4dd8c823af5442401c
CPU threads: 8; OS: Linux 5.15; UI render: default; VCL: gtk3
Locale: en-AU (en_AU.UTF-8); UI: en-US
Calc: threaded