Wrong positioned connectors within a jsPlumb container with CSS position absolute or relative

[GoogleCodeExporter]

When I try to use jsPlumb in a container different from the body element, I get 
an incorrect behavior when dragging an endpoint. 

The connector is drawn with the wrong offset, it takes the document as a 
reference where it should use its parent position (jQuery's offset() vs 
position()). Also when the drag is aborted, the connector canvas is not 
destroyed.

A page showcasing the issue can be found here:
http://sandbox.gocomplex.net/plumb/draggableConnectorsDemo.html

Original issue reported on code.google.com by sylvain....@gmail.com on 16 Sep 2010 at 1:15

[GoogleCodeExporter]

Adding a screenshot showing the issue.

Original comment by sylvain....@gmail.com on 16 Sep 2010 at 1:17

Attachments:

• jsPlumb-bug.jpg

[GoogleCodeExporter]

have you seen this demo?

http://morrisonpitt.com/jsPlumb/html/jquery/multipleJsPlumbDemo.html

Original comment by simon.po...@gmail.com on 17 Sep 2010 at 2:55

[GoogleCodeExporter]

Of course, one of the first things I saw when I discovered this lib.

But this demo allows to drag containers and endpoints, but you can't draw new 
connectors by dragging an endpoint, like in my modified demo.

Original comment by sylvain....@gmail.com on 17 Sep 2010 at 8:45

[GoogleCodeExporter]

ha, yes, good point.  i'll take a look.

Original comment by simon.po...@gmail.com on 18 Sep 2010 at 5:17

[GoogleCodeExporter]

i've put a fix in for this in 1.2.3-RC1. you can see your demo running with 
that version here:

http://morrisonpitt.com/jsPlumb/tests/issue23_test.html

i haven't tested on MooTools yet. when i do i will close this issue and 
probably release 1.2.3.

Original comment by simon.po...@yahoo.com on 19 Sep 2010 at 12:24

[GoogleCodeExporter]

I'v tested the fix, and the canvas position is correct now.

But I am wondering if recalculating the parent relative position, at each step 
of the dragging, is a big performance hit or not.

jQuery UI provides you a 'position' object within it's ui object, and as for 
mootools I can't say.

Original comment by sylvain....@gmail.com on 22 Sep 2010 at 2:18

[GoogleCodeExporter]

does the dragging keep up with you when you move the mouse?

Original comment by simon.po...@gmail.com on 22 Sep 2010 at 2:55

[GoogleCodeExporter]

Yes, the animation is smooth, even in IE6!

But code-wise, fetching the container offset in the drag callback seems 
redundant, since it does not change while dragging.

Original comment by sylvain....@gmail.com on 22 Sep 2010 at 6:35

[GoogleCodeExporter]

you are right; it will never change, will it.  i'll leave this issue open until 
i find a decent place to cache the offset after the first lookup.

btw - even in IE6?  how cool!

Original comment by simon.po...@gmail.com on 22 Sep 2010 at 6:48

• Changed state: Started

[GoogleCodeExporter]

Ok, so I found a improved fix for this issue while trying to fix another one, 
related to the use of a container with overflow:scroll.

This demo : http://sandbox.gocomplex.net/plumb/draggableConnectorsDemo.htm 
shows the issue when you try to exit the initial boundaries of the container, 
the dragged connector will get 'stuck'
It seems ui.offset does not include the scroll...

But ui.position seems to do, so I created this jQuery agnostic function and 
called it in the drag event callback:

getUIRelativePosition: function(eventArgs) {
   var ui = eventArgs[1];
   return ui.position ;
}
It fixed the problem and resolved this parent offset calculation thing, since 
position is relative to the parent.

But two bugs remain: the droppable endpoints kind of stopped working, and the 
painted Endpoints are sometimes in the wrong place.

I will try to investigate this issue if you agree, since it seems I am the only 
one who needs such advanced interactions :)

Original comment by sylvain....@gmail.com on 24 Sep 2010 at 2:59

[GoogleCodeExporter]

Here is the half-working fix demo:
http://sandbox.gocomplex.net/plumb/fix/draggableConnectorsDemoFix.htm

Original comment by sylvain....@gmail.com on 24 Sep 2010 at 3:00

[GoogleCodeExporter]

the overflow:scroll problem you mentioned seems to be the same as reported in 
issue 37.  bumping this to high and targeting 1.2.4.

Original comment by simon.po...@gmail.com on 21 Oct 2010 at 9:27

• Added labels: Priority-High
• Removed labels: Priority-Medium

[GoogleCodeExporter]

Nice! Tell me if you need some help.

Original comment by sylvain....@gmail.com on 22 Oct 2010 at 12:23

[GoogleCodeExporter]

Sylvain,

I've got a test page for this now which seems to show that the scrolling only 
fails when you're dragging the _target_ element in a given connection.  when i 
drag the source element the scrolling is calculated correctly.  does this 
happen for you?

Original comment by simon.po...@gmail.com on 25 Oct 2010 at 6:20

[GoogleCodeExporter]

Yes I was able to reproduce this one, it seems when you drag the target, the 
source endpoint is "stuck" at the same coordinates, ignoring the scroll 
offset...

If I remember in one of my previous experiments I found out that jQuery's 
offset() is only about the document offset, if you scroll an element it will 
visually stay at the same place, ignoring the scroll value.

Original comment by sylvain....@gmail.com on 25 Oct 2010 at 10:03

[GoogleCodeExporter]

closing this.  the thread can be followed in issue 37.

Original comment by simon.po...@gmail.com on 19 Dec 2010 at 10:06

• Changed state: Fixed