Description: While Writer load background image from document, open the Page Style dialog, click Area tab, the image can be seen at the Preview area, but can’t be seen at the Bitmap list, making it impossible to switch back if this image is replaced by other image and before the document is saved. Steps to Reproduce: 1. Open Wood.odt from my attachment 2. Click Format -> Page -> Area Actual Results: The wooden background can be seen at the Preview, but it can’t be seen at the Bitmap list. Expected Results: The wooden background should also available at the Bitmap list. If this image is replaced by another image, the document is saved, and Writer is closed, this image can be dropped from the Bitmap list. Reproducible: Always User Profile Reset: No Additional Info: 版本: 6.3.0.0.beta1 (x64) Build ID: a187af327633f5f00363be5131bd21a13e0f1a7b CPU 线程: 4; 操作系统: Windows 10.0; UI 渲染: 默认; VCL: win; 区域语言: zh-CN (zh_CN); UI 语言: zh-CN Calc: threaded
Created attachment 152249 [details] Sample file
Created attachment 152250 [details] My snapshot This is my snapshot, notice that the Page Style dialog is resized to larger size.
On pc Debian x86-64 with master sources updated today, I could reproduce this. I suppose a good start should be in this file: https://opengrok.libreoffice.org/xref/core/cui/source/tabpages/tpbitmap.cxx
(In reply to Julien Nabet from comment #3) > On pc Debian x86-64 with master sources updated today, I could reproduce > this. > > I suppose a good start should be in this file: > https://opengrok.libreoffice.org/xref/core/cui/source/tabpages/tpbitmap.cxx Let's turn this into an easyhack then...
I am familiar with this problem and I can solve it.
*** Bug 134259 has been marked as a duplicate of this bug. ***
Version: 7.0.0.3 (x64) Build ID: 8061b3e9204bef6b321a21033174034a5e2ea88e CPU threads: 4; OS: Windows 10.0 Build 19041; UI render: Skia/Raster; VCL: win Locale: en-GB (en_GB); UI: en-GB Calc: threaded Bug still present in this version.
Dear duuxixu, This bug has been in ASSIGNED status for more than 3 months without any activity. Resetting it to NEW. Please assign it back to yourself if you're still working on this.
Hello I want to work on this bug. Progress made in solving the bug- In file cui/source/tabpages/tpbitmap.cxx SvxBitmapTabPage::Reset performs the actions when user clicks on the bitmap section in Format->PageStyle->Area tab . IMPL_LINK_NOARG(SvxBitmapTabPage, ModifyBitmapHdl, ValueSet*, void) performs actions when user clicks on the default bitmaps present and add the bitmap into the preview . IMPL_LINK_NOARG(SvxBitmapTabPage, ClickImportHdl, weld::Button&, void) performs actions when user clicks on add/import button and new image is added in the bitmaps. The idea to solve the bug is to get the image from the background and add it into the bitmaps and into the preview which can't be done in the file cui/source/tabpages/tpbitmap.cxx because no idea of how to retrieve the background image. This is the idea i could think of with the pointers(cui/source/tabpages/tpbitmap.cxx) provided in the bug. Correct me if i am wrong at any point and please provide more pointers or some guidance to solve the bug.
Since Tushar Kumar Rai assigned himself recently, let's put it back to ASSIGNED. Tushar: you can discuss with LO Devs on IRC or ask on dev LO forum.
> Tushar: you can discuss with LO Devs on IRC or ask on dev LO forum. Sure. I was busy working on Gsoc proposal and am working on different patch now. Will assign it to myself after finishing.
The page area dialog does not work as the dialog used for shapes, see bug 103916.
Started in 5.3, when the dialog was redone to add new images to the list, and allow naming them. (libreoffice-5.3.0.0.alpha1 in linux-64-releases bibisect repo.) Same happens with e.g. Draw's Page > Page Properties > Background > Image. 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
*** Bug 130543 has been marked as a duplicate of this bug. ***
This is also true for the dropdowns in the Properties (for Draw/Impress) or Page (for Writer) sidebar decks, as mentioned in bug 130543 comment 5.
*** Bug 108905 has been marked as a duplicate of this bug. ***
Setting priority back to "normal": 3 duplicates; functionality seems broken; it affects more than Writer; and more than page background (e.g. paragraph styles too).
WIP fix at https://gerrit.libreoffice.org/c/core/+/176253. The biggest problem is that these auto-added backgrounds should NOT persist beyond the document itself. The big test for this would be to auto-add a background from an imported file, and then (using a textbox) to deliberately add/import a JPG. While that intentionally added JPG should be permanent, the auto-added one should not be permanent. Note that prior to bug 163824, non-editeng backgrounds works "as hoped for" - i.e. they only existed in the current document. So it SHOULD be enough to simply never write these bitmaps to the user profile. I say simply... I wonder if it can be filtered out by URL?
(In reply to Justin L from comment #18) > I wonder if it can be filtered out by URL? No - none of the predefined items have a getOriginURL. At this point I have no idea how this could be possible. The only point that "save" iterates through the individual items is in svx/source/xml/xmlxtexp.cxx where everything is already reduced to a simplistic XNameContainer. This is not an easyHack.
Justin Luth committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/a366cd34a85a21210939482d229d6d2dd9c1087c tdf#125969 cui: add in-use area image to bitmap list It will be available in 25.8.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.
(In reply to Commit Notification from comment #20) > Justin Luth committed a patch related to this issue. > It has been pushed to "master": > > https://git.libreoffice.org/core/commit/ > a366cd34a85a21210939482d229d6d2dd9c1087c > > tdf#125969 cui: add in-use area image to bitmap list > > It will be available in 25.8.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. I Justin, This commit breaks the test test_tdf145158 associated to the fix for bug #145158. Git does not accept to revert your commit to check, but at the parent commit the test passes and from your commit the test fails. My build is done on Ubuntu 22.04 x86-64 with gcc-13. Please, could you have a look ? Best regards. JBF
I could not reproduce the UITest failure on my Ubuntu 24.04 machine (testing with a clean profile). In one terminal I ran: LANG=C SAL_USE_VCLPLUGIN=gen make debugrun In the other terminal, I ran - make gb_UITest_DEBUGRUN=T UITest_writer_tests8 UITEST_TEST_NAME=tdf125969.tdf125969.test_tdf125969 - then make gb_UITest_DEBUGRUN=T UITest_writer_tests8 UITEST_TEST_NAME=tdf145158.tdf145158.test_tdf145158 both passed. It also passed when I did all of the writer8 tests. - make gb_UITest_DEBUGRUN=T UITest_writer_tests8 I'll test again on an Ubuntu 20.04 box, once it finishes compiling (I saw the failure, but it was in a very dirty environment - without this bug's patch, but WITH this bug's unit test...). I don't see any possible relation between these two tests. I don't open the character dialog... Things to try for those having a problem. -run my test after tdf145158 (I believe they run based on alphabetical sort) (In reply to Jean-Baptiste Faure from comment #21) > Git does not accept to revert your commit to check, It should work if you first revert ab314514f9cc422c6018ec3b387c730afa1de817
(In reply to Justin L from comment #22) > I'll test again on an Ubuntu 20.04 box I can't reproduce here either. All uiwriter8 unit tests pass for me.
Same issue on my build on openSUSE tumbleweed up to date fyi
Created attachment 198147 [details] My autogen.input Hi, I just attached my autogen.input with which the test fails. Best regards. JBF
(In reply to Jean-Baptiste Faure from comment #25) Well, the code shouldn't be too hard to follow. Since you can reproduce it, you can just start disabling parts and see what part breaks it. The first thing I would do would be to simply delete the .py unit test. My suspicion is that the mere presence of the test must be altering the expected environment somehow. If it is affected by the actual code changes, I'd start with - if (!pEntry->GetSavingAllowed()) + if (!pEntry->GetSavingAllowed() && false) and then - if (nPos == -1) + if (nPos == -1 && false)
Justin I've not done the test you mentionned but FYI the problem seems to occur only on french people, perhaps an issue related to locale
Is it possible to backport to 25.8 release channel?
Is it possible to backport to 25.2 release channel?
(In reply to Volga from comment #29) > Is it possible to backport to 25.2 release channel? based on comment 21, that doesn't sound like a good idea.