Bug 120539 - Position of adjusted middle line on connectors is randomly changed when copying the drawing to a writer document
Summary: Position of adjusted middle line on connectors is randomly changed when copyi...
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Draw (show other bugs)
Version:
(earliest affected)
6.1.0.3 release
Hardware: All All
: medium normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords: notBibisectable, regression
Depends on:
Blocks: Connectors
  Show dependency treegraph
 
Reported: 2018-10-12 08:58 UTC by user234683
Modified: 2023-10-28 16:34 UTC (History)
5 users (show)

See Also:
Crash report or crash signature:


Attachments
Demonstration of bug (51.51 KB, image/png)
2018-10-12 09:00 UTC, user234683
Details
sample file (8.75 KB, application/vnd.oasis.opendocument.graphics)
2018-11-13 10:55 UTC, Xisco Faulí
Details
working example (9.00 KB, application/vnd.oasis.opendocument.graphics)
2018-12-13 10:30 UTC, user234683
Details

Note You need to log in before you can comment on or make changes to this bug.
Description user234683 2018-10-12 08:58:57 UTC
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
Comment 1 user234683 2018-10-12 09:00:40 UTC
Created attachment 145633 [details]
Demonstration of bug
Comment 2 user234683 2018-10-12 09:08:36 UTC
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.
Comment 3 Xisco Faulí 2018-11-13 10:55:19 UTC
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
Comment 4 Xisco Faulí 2018-11-13 10:55:32 UTC
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.
Comment 5 user234683 2018-12-13 10:30:20 UTC
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.
Comment 6 user234683 2018-12-13 10:41:25 UTC
Tested on 6.1.3.2 and it still occurs.
Comment 7 Regina Henschel 2018-12-13 14:58:29 UTC
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
Comment 8 Xisco Faulí 2018-12-18 13:13:37 UTC
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
Comment 9 Terrence Enger 2019-01-04 04:05:17 UTC
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.
Comment 10 Buovjaga 2020-06-05 15:59:10 UTC
(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.
Comment 11 QA Administrators 2022-06-06 03:26:59 UTC Comment hidden (obsolete)
Comment 12 Regina Henschel 2023-10-28 16:34:35 UTC
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