Created attachment 186088 [details] Example file from Calc Attached example file contains two form controls on the second sheet. When the sheet is copied into a new file, the form controls appear mispositioned. 1. Open attached file 2. Right click on Sheet1, select Move or Copy Sheet 3. In the To Document choose: - new document - 4. Observe that the Push Button and the dropdown list appear in the new document somewhat to the bottom right compared to their original position. As if their X and Y coordinate values have been doubled, but the Control Properties dialog shows the same X: 4.98 cm and Y: 3.61 cm as originally. Also when selected the highlight boxes appear in the correct position. Important circumstances: the sheet has to be NOT the first in the document, if it's first then the positioning is fine. The form controls have to be anchored as "To Cell", the default case of "To Page" works fine. Version: 7.6.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: b5c3a7502f7ff6ccf0f829c1f3a2ba50b8584c41 CPU threads: 14; OS: Windows 10.0 Build 19045; UI render: Skia/Raster; VCL: win Locale: en-US (hu_HU); UI: en-US Calc: threaded Started to behave like this in 4.0. Was good in: Version 3.6.0.4 (Build ID: 932b512)
Created attachment 186089 [details] Screenshot of the issue in the example file and in the copy of the Sheet1 sheet
Still REPRODUCIBLE with reporter's sample document and Server Installation of Version: 7.6.0.0.alpha0+ (X86_64) Build ID: 0484a9a3f5e2ecb678f6fb41bbb251529e89c00d CPU threads: 12; OS: Windows 10.0 Build 19044; UI render: Skia/Raster; VCL: win Locale: de-DE (de_DE); UI: de-DE Calc: CL threaded – Special new User Profile for testing Already REPRODUCIBLE (not exactly the sanme, but very similar) with Server Installation of Version: 4.0.0.3 WIN10 Build-ID 7545bee9c2a0782548772a21bc84a9dcc583b89; Special devUserProfile Currently I do not have the time for more investigation (DUPs ...)
Version: 7.5.1.2 (X86_64) / LibreOffice Community Build ID: fcbaee479e84c6cd81291587d2ee68cba099e129 CPU threads: 4; OS: Windows 10.0 Build 19044; UI render: Skia/Raster; VCL: win Locale: ro-RO (ro_RO); UI: en-GB Calc: CL threaded reproducible
bibisected with linux-41max repo and got the following results: 17c8d9a064bd9a21f0a7b595758803df0f20633f is the first bad commit commit 17c8d9a064bd9a21f0a7b595758803df0f20633f Author: Matthew Francis <mjay.francis@gmail.com> Date: Fri Sep 18 10:22:49 2015 +0800 source-hash-bdb66834887ec58cd9c602841c185a6629b13d6b commit bdb66834887ec58cd9c602841c185a6629b13d6b Author: Noel Power <noel.power@suse.com> AuthorDate: Wed Jan 23 15:25:41 2013 +0000 Commit: Noel Power <noel.power@suse.com> CommitDate: Wed Jan 23 15:54:37 2013 +0000 1837: don't use ScDrawLayer::GetObjDataTab to get Anchor fix for fdo#59325 | https://gerrit.libreoffice.org/c/core/+/1837 adding Noel to Cc
(In reply to Steve271 from comment #4) > adding Noel to Cc Allow me to doubt that there will be a reply from Noel Power in a timely manner. Some other dev with relevant knowledge would need to take this (and therefore, probably the report would need a higher-than-normal priority).
(In reply to ady from comment #5) > > Allow me to doubt that there will be a reply from Noel Power in a timely > manner. > > Some other dev with relevant knowledge would need to take this (and > therefore, probably the report would need a higher-than-normal priority). Understood. no rush as this doesn't seem like a critical bug
Just finished a Bugzilla search and based on the information I came across, this issue is a duplicate of bug 94921. I'm going to mark this bug RESOLVED DUPLICATE *** This bug has been marked as a duplicate of bug 94921 ***