Have a look at https://bugs.documentfoundation.org/attachment.cgi?id=199771 There could be seen some listboxes in this screenshot. All dropdown for the listboxes where positioned wrong when editing the form. Dropdowns for Dates will positioned right. You could test the same with a new created form in Writer: Open Writer → Form → List Box. Create a listbox for database bibliography. Have a look at the box after it has been created. Bug will appear. There are some more bugs: Backbround of all controls will be moved a little bit upper left. So border on the left and border on top of every control couldn't be seen. Navigationsbars will show the content positioned wrong, partly out of the background. Will wait to write bugs for this until the totally wrong position will be fixed.
I can reproduce with an additional step to enable the dropdown: (In reply to Robert Großkopf from comment #0) > You could test the same with a new created form in Writer: > Open Writer → Form → List Box. > Create a listbox for database bibliography. * Right-click the control -> "Control Properties" * in the "General" tab, set "Dropdown" to "Yes" Version: 25.8.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: 7b9e27da2033192c628b23e4e1686209e951dadb CPU threads: 32; OS: Linux 6.12; UI render: default; VCL: qt6 (cairo+wayland) Locale: en-GB (en_GB.UTF-8); UI: en-US Calc: threaded
Created attachment 199773 [details] Sample document to reproduce Alternative steps to reproduce: 1) open attached sample doc 2) Enable "Form" -> "Design Mode" Also reproducible with the gtk3 VCL plugin.
Regression, bibisected to: commit 7c0d5fab2b62a9cb79e228e372bb85d38fe73bcc Author: Armin Le Grand Date: Thu Jan 30 20:47:00 2025 +0100 tdf#164476 CiaroSDPR: improve ControlPrimitive2D rendering CC'ing Armin
Could reproduce (do not forget to go to design mode). Checked using DISABLE_SYSTEM_DEPENDENT_PRIMITIVE_RENDERER=1 that it is SDPR. Thanks for bibisect, taking a look...
Hmmm. (a) The part in drawinglayer/source/processor2d/cairopixelprocessor2d.cxx is correct, the coordinates are correct and the MapMode of the target- OutDev is correct since it's not changed in createPixelProcessor2DFromOutputDevice when the CairoPixelProcessor2D is created. Controls with 'single' window are rendered correctly. Controls with 'sub-content' do not, the sub-windows are misplaced. (b) It's the same part as in drawinglayer/source/processor2d/vclpixelprocessor2d.cxx (grep for ::processControlPrimitive2D to find both), except for also using mpOutputDevice->GetMapMode().GetOrigin(), but of course uses the local OutDev for primitive rendering, but *not* while calling xControlView->draw (c) The decompose fallback for primitive2d::ControlPrimitive2D also uses the UNO API draw with a position, that also works. It renders to a temp VDev. Problems are that the resolution gets reduced when too big, but also tdf#164476 which *somehow* needs the call to UNO API draw to get the Controls *incarnated* and appearing (an error in itself...) So I do not really know what to do. (a) *should* work, I have no idea why the needed offsets in the internal stuff for draw do not work, I guess that is also an error.
Checked again with SDPR disabled, the const Point aOrigin(mpOutputDevice->GetMapMode().GetOrigin()); in VclPixelProcessor2D::processControlPrimitive2D is (0, 0) in the bugdoc, so that excludes this as source of the problem.
@Caolan: Looks as if calling awt::XGraphics::draw with the correct coordinates in CairoPixelProcessor2D::processControlPrimitive2D after loading bugdoc from comment2 and switching to design mode in menu/form/DesignMode does not paint sub-windows correctly. It works for 'simple' FormControls without sub-windows, so the call and coordinates seems correct. I tried to debug into that draw impl, it seems to 'bend' ptrs between OutDens & Windoes to get a Control painted to a target device outside of the normal windows paint. This seems to work in principle, if you do the same using DISABLE_SYSTEM_DEPENDENT_PRIMITIVE_RENDERER=1 the same call in VclPixelProcessor2D::processControlPrimitive2D does the right thing. I hope you know more about that FormConrol rendering stuff and could give hints why in that case the offsets to render that sub-content 'windows' seems to go wrong...?
Identified the problem: Indeed the MapMode is the cause: - For 'simple' FormControls the orig MapMode of target OutDev works - For 'combined' ones it *MUST* be unset AKA No MapMode Not sure why this is needed, but indeed in VclPixelProcessor2D::VclPixelProcessor2D there is // prepare output directly to pixels mpOutputDevice->Push(vcl::PushFlags::MAPMODE); mpOutputDevice->SetMapMode(); and in VclPixelProcessor2D::~VclPixelProcessor2D // restore MapMode mpOutputDevice->Pop(); so that this is no problem here. In CairoPixelProcessor2D it is *indirectly* a problem since the used setXGraphics(rTargetOutDev.CreateUnoGraphics()) and the used mechanism to render FormControls does indirectly use the OutputDevice, even if not available in CairoPixelProcessor2D. ARGH!
Armin Le Grand (Collabora) committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/6a7e2f4ba5581946adf26195f0782f938c56919f tdf#165706: Fix visualization of MultiFirmControls in EditMode 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.
Fix is on https://gerrit.libreoffice.org/c/core/+/183196. This fixes the problem in vcl by making Window::ImplPaintToDevice work even when a MapMode is set for the sub-content windows.
While this task is fixed with the 1st commit I decided to add some more care to the CairoSDPR implementation, see https://gerrit.libreoffice.org/c/core/+/183204
Armin Le Grand (Collabora) committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/7a1de78ec2e58d2cceded3bf03c0c3c3cccc675a tdf#165706 additional taking care in CairoSDPR 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.
Armin Le Grand (Collabora) committed a patch related to this issue. It has been pushed to "libreoffice-25-2": https://git.libreoffice.org/core/commit/f2305b96b797c2084426eb2395d3ebd3b7d1fec5 tdf#165706: Fix visualization of MultiFirmControls in EditMode It will be available in 25.2.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.