Sometimes dragging "loses" the object

[uliska]

We still have the problem that sometimes one can "lose" the dragged object. By now I'm convinced this has to be dealt with in the leave (i.e. onmouseout) signal.

I think what happens is:

• somehow the onmouseout event is triggered (maybe mouse moves faster than the dragging is processed, or onmousemove is triggered at a moment when the mouse is already out of the object's area).
• The draggedObject still exists, confusing the onmousemove entry check.
• mouse can move around freely, while the object "hangs around").
• when the mouse touches the object again, dragging is continued, even when the mouse has already been released.

As this problem hasn't got worse since the last pull request I think we can postpone this issue until after the pull request. Actually I think our position to solve the issue is much better now than it had been previously because the code is much more structured now.

[PeterBjuhr]

I think this is related to the issues #21 and #22.

[uliska]

Maybe it's as simple as wrapping leave() with

if (draggedObject) ...

[PeterBjuhr]

I think the serious part of this issue is that the onmouseout event is fired at all. That means that the dragging doesn't work as good as expected. It's this that should be discussed, and I have started in issue #22.

The other part is: Could we improve the behavior if the onmouseout event occurs? I think this could be quite straightforward to deal with. Maybe we should just equate this with a mouseup event and call the MouseUp function!??

To summarize: we should focus on preventing the onmouseout to occur doing dragging; but maybe we can't totally prevent it from happening, then we should of of course handle this better than is done at the moment.

[uliska]

I think the following happens:

• a mousemove event isn't triggered on every pixel but after a given timespan
• the mouse has moved by a certain amount in that time
• if the mouse is out of the object at that time the onmouseout is triggered before onmousemove.

So what I think will easily solve the issue would be to check when entering onmouseout if we're currently in a dragging process.
This could easily be done by checking if a draggedObject is present. The problem is that currently leave() and MouseMove() are in different files, so in leave() there never is that object available.

But basically this issue should be easily and persistently be solvable.

[PeterBjuhr]

You don't need the leave function. For debugging purposes you could set up something like this:

onmouseout = function (e) { pyLinks.pyLog(draggedObject); };

[PeterBjuhr]

...or if you want something a little more permanent add it to the collectElements function. In the for loop add:

draggable[t].onmouseout = MyNewFunction;

[PeterBjuhr]

...but you may need to comment out this line in view.py:

frame.evaluateJavaScript(getJsScript('pointandclick.js'))

[PeterBjuhr]

But (more importantly) for me the root of the problem must be in the current implementation of the dragging functionality. You have yourself reported that moving an object less than 0.15 isn't possible. And it makes the dragging very unstable for smaller objects.

If you don't mind I think we should focus on that problem as described in #21 and #22. (But we can of course discuss it anywhere you like...)

[uliska]

I just made a test and added a "hook" in the leave function (that I had moved to editsvg.js. When entering the function it reported back whether draggedObject was present.

This confirms: "Losing" the dragged object occurs when onmouseout is triggered while dragging an object.

Unfortunately it doesn't help to simply discard the onmouseout event in this case - the object is lost anyway.

[uliska]

That means: even if I don't understand yet why you're so sure about the relation with the other issues I'm OK to leave that one open and see what happens after solving the other ones.

[PeterBjuhr]

Unfortunately it doesn't help to simply discard the onmouseout event in this case - the object is lost anyway.

Yes, when the onmouseout event is triggered it's too late to do anything about it. But what we should do is to set the draggedObject to null to prevent some of the other unwanted behavior.

[PeterBjuhr]

That means: even if I don't understand yet why you're so sure about the relation with the other issues I'm OK to leave that one open and see what happens after solving the other ones.

I'm sorry that I can't make my view clearer! I'll try one more time:

All the positions are rounded to two decimals. From that it would be expected that the smallest step would be 0.01, so why it's 0.15 I don't know at the moment (#21). Anyway it makes the correspondence between the mouse movement and the objects movement less exact. (As reported in #22, it works quite well when dragging text but for other elements it's unstable.)

I propose that we explore #21 first and see if we can reach the expected 0.01 and how that improves the dragging.

If that doesn't work I think we shall consider going back to the idea I implemented first, to not apply the round until the mouseup event. That way we can ensure the best possible correspondence between mouse and object during dragging. (It was after all for that reason I choose that solution...)