Description: When a drawing has a connector between objects, and the middle line of the connector has been moved significantly, and the whole drawing is selected and copy and pasted into a writer document, the middle line will be offset randomly. See attached image. Steps to Reproduce: 1. Create a connector between two objects in draw. Make sure you form a connector with an adjustable middle line. 2. Move the middle line by a significant amount. Moving it to imitate a connector with only two lines is generally enough. If the bug isn't reproduced, try moving it farther. 3. Select the whole drawing. Copy and paste it into a writer document Actual Results: The middle line of the connector in the pasted drawing is offset randomly, neither to where it started originally nor where it was moved to. Expected Results: The middle line should remain where it was in drawing. Reproducible: Always User Profile Reset: Yes Additional Info: Resizing the pasted drawing at all will reset the middle line to its original position when the connector was created (NOT the position it was adjusted to in step 2.) The bug happens with and without "Use OpenGL for all rendering" enabled. But regardless of whether I have that enabled there's some text below it that says "GL is currently disabled." Not sure if that refers to OpenGL. Version: 6.1.1.2 (x64) Build ID: 5d19a1bfa650b796764388cd8b33a5af1f5baa1b CPU thread: 4; OS: Windows 6.1; UI render: default; Locale: en-US(en_US); Calc: group threaded
Created attachment 145633 [details] Demonstration of bug
Forgot to mention. I don't believe this is related to https://bugs.documentfoundation.org/show_bug.cgi?id=54355 which is somewhat similar. Zooming has no effect whatsoever on it, and grouping the drawing before copying it doesn't prevent it.
Created attachment 146588 [details] sample file I can't reproduce it using the attached document Versió: 6.1.3.2 ID de la construcció: 1:6.1.3~rc2-0ubuntu0.16.04.1 Fils de CPU: 4; SO: Linux 4.15; Renderitzador de la IU: per defecte; VCL: gtk3; Configuració local: ca-ES (ca_ES.UTF-8); Calc: group threaded
Could you please try to reproduce it with the latest version of LibreOffice from https://www.libreoffice.org/download/libreoffice-fresh/ ? I have set the bug's status to 'NEEDINFO'. Please change it back to 'UNCONFIRMED' if the bug is still present in the latest version.
Created attachment 147491 [details] working example Here's an example which I've just tested with Libreoffice 6.1.4.1 The reason your sample doesn't exhibit the bug is because it doesn't have the middle line (the connector needs to have a total of 3 lines, and the middle line needs to be adjusted from its default position). So the connector needs to be between two points such that the middle line is present. The position of this adjusted middle line is messed up when copying it into a writer document. Once the update is finished on my other computer, I'll test it on 6.1.3 as you requested.
Tested on 6.1.3.2 and it still occurs.
I see the described problem in Version: 6.1.3.2 (x64) Build-ID: 86daf60bf00efa86ad547e59e09d6bb77c699acb CPU-Threads: 8; BS: Windows 10.0; UI-Render: Standard; Gebietsschema: de-DE (en_US); Calc: CL
Reproduced in Version: 6.3.0.0.alpha0+ Build ID: 6dc36d343aeacb3d1e14ec0c847937d63f4e68a7 CPU threads: 4; OS: Linux 4.15; UI render: default; VCL: gtk2; Locale: ca-ES (ca_ES.UTF-8); UI-Language: en-US Calc: threaded but not in Version: 5.4.0.0.alpha1+ Build ID: 9feb7f7039a3b59974cbf266922177e961a52dd1 CPU threads: 4; OS: Linux 4.15; UI render: default; VCL: gtk3; Locale: ca-ES (ca_ES.UTF-8); Calc: group
Working on debian-buster with bibisect-linux-64-6.1 repository, I find that that bug entered LibreOffice somewhere in roughly 1200 commits: commit s-h date -------- -------- ---------- bfr first crash c5420f11 e1b247a8 2018-04-06 first crash c91d6907 6c14c27c 2018-04-06 last crash 083cb644 bdccb7e9 2018-05-07 aft last crash c28a56d0 91b0d212 2018-05-07 Each crash was a Signal 6. The commits from "first crash" to "last crash", so far as I probed them, terminated with Signal 6 upon <Ctrl>+V in Writer. Some later commits, starting with the one labelled "aft last crash" displayed the expected result after <Ctrl>+V in Writer and then terminated with Signal 6 upon <Ctrl>+Q. I have not made any attempt to dig into the crashes. I am leaving keyword bibisectRequest: perhaps the crash is peculiar to my setup.
(In reply to Terrence Enger from comment #9) > Working on debian-buster with bibisect-linux-64-6.1 repository, I find > that that bug entered LibreOffice somewhere in roughly 1200 commits: > > commit s-h date > -------- -------- ---------- > bfr first crash c5420f11 e1b247a8 2018-04-06 > first crash c91d6907 6c14c27c 2018-04-06 > last crash 083cb644 bdccb7e9 2018-05-07 > aft last crash c28a56d0 91b0d212 2018-05-07 > > Each crash was a Signal 6. The commits from "first crash" to "last > crash", so far as I probed them, terminated with Signal 6 upon > <Ctrl>+V in Writer. Some later commits, starting with the one > labelled "aft last crash" displayed the expected result after <Ctrl>+V > in Writer and then terminated with Signal 6 upon <Ctrl>+Q. I have not > made any attempt to dig into the crashes. > > I am leaving keyword bibisectRequest: perhaps the crash is peculiar to > my setup. I get the crashes as well with win32-6.1. I still repro the pasting issue with master.
Dear user234683, To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year. There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present. If you have time, please do the following: Test to see if the bug is still present with the latest version of LibreOffice from https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the information from Help - About LibreOffice. If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a comment that includes the information from Help - About LibreOffice. Please DO NOT Update the version field Reply via email (please reply directly on the bug tracker) Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not appropriate in this case) If you want to do more to help you can test to see if your issue is a REGRESSION. To do so: 1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) from https://downloadarchive.documentfoundation.org/libreoffice/old/ 2. Test your bug 3. Leave a comment with your results. 4a. If the bug was present with 3.3 - set version to 'inherited from OOo'; 4b. If the bug was not present in 3.3 - add 'regression' to keyword Feel free to come ask questions or to say hello in our QA chat: https://web.libera.chat/?settings=#libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug
It is an error with using the leaving direction of the diagonal gluepoint of the ellipse. The error still exists in Version: 24.2.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: 1b0e7f76820d467dd0d98962b01f84cb38a3a985 CPU threads: 8; OS: Windows 10.0 Build 19045; UI render: default; VCL: win Locale: de-DE (de_DE); UI: en-US Calc: CL threaded