In the page/paragraph properties dialog, there is an "area" tab to set the background to an image. A set of images is provided, with the ability to add new ones. However, any newly added images are not saved or made available to a new document. But, if you add an image via a textbox's area property, then it IS saved in the user profile, and is available again the next time LibreOffice is started. Similarly, page/paragraph cannot (permanently) delete a user-added image, but if done via the textbox area, it will be removed. Steps to reproduce. 1.) start a new writer document. Go to Format - Page Style -Area tab - Image, and add-import a JPG. 2.) start a second new document. Same steps - and the added JPG is not available. 3.) Insert - Textbox with some text. Select the textbox (click on the border) and go to the Format menu- Text Box and Shape - Area, and add-import a JPG. 4.) start a third new document. Same steps - and the added JPG is available (but can't be deleted from here, only from the shape Area dialog). Already true in the previous version of the dialog (tested LO 5.2). The current dialog was created in LO 5.3 (for both sw and editeng components) acting as described here. Tested and failed with SW page/header/paragraph/table/frame. Tested and failed with Calc page Tested and failed with Draw page
The problem exists for gradients too, see bug 103916. The report here is likely duplicate to bug 125969.
SvxBitmapTabPage is created in two places. The most common way is the generic SfxTabDialogController::CreatePages() which creates a SvxAreaTabPage. This way does NOT save BitmapList changes. The other place is SvxAreaTabDialog which creates the same SvxAreaTabPage, but this one keeps track of the Lists, and SavePalettes() on both OK and Cancel. It will not be trivial to fix this. [DeactivatePage is called on OK, but not on cancel - likely a failure of IMPL_LINK_NOARG(SfxTabDialogController, CancelHdl) which does not PrepareLeaveCurrentPage().] [ChangesApplied is never called.] When designing this, keep in mind the desire of bug 125969 to be able to auto-add images that must NEVER be saved to the user profile - but only remain available for the current document.
The only thing I can think of is to move the save into DeactivatePage. OR else to call DeactivatePage on cancel and extend enum class DeactivateRC to call back a new DialogClosing function. OR else to extend SfxOkDialogController to request a call-back on dialog close. (In reply to Justin L from comment #2) > likely a failure of IMPL_LINK_NOARG(SfxTabDialogController, CancelHdl) > which does not PrepareLeaveCurrentPage(). Better in this case would be to simply call DeactivatePage(nullptr). It has always been like this since initial implementation with commit 28fc0962b10519ab84654d189d2ad0cca8f84f95 Author: Caolán McNamara on Tue Apr 24 14:14:34 2018 +0100 weld SwLabDlg The impact of using DeactivatePage is that this would avoid saving on a CANCEL (which could make sense to me) - although that could be worked around simply by first moving to a different tab/page before cancelling. Ahh - actually the Destructor works very nicely.
*** Bug 151177 has been marked as a duplicate of this bug. ***
Justin Luth committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/6595fcacfa9afb5f09465785aa0c4af46e972ef0 tdf#103916 tdf#163824 cui tparea: always save changed Fill Lists It will be available in 25.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.