Handoff of service dragging defect

[Matthew Scott]

All,

This is in regards to the bug in dragging services while a delta is in
progress[1].  Specifically, it relates to annotations and storing the
x/y coordinate on drag-end from a previous service drag.  I was able to
do some research today and have some ideas, though I was not able to
implement anything.  In short, here's how to reproduce:

1.  Drag a service and let it go.
2.  Immediately drag another service.
3.  Keep dragging it around.

What happens: The service you're dragging around will eventually stop
even though you're still holding down the mouse button and moving the
cursor.

What should happen: You should still be dragging the service around.

What's going on behind the scenes:

1.  When you drop the first service, its coordinate annotations are
updated over the websocket.
2.  If you start dragging the second service immediately, there is a
chance that juju hasn't responded with an result response or a delta
containing a confirmation.
3.  The result response or the delta is received while you're dragging.
4.  on_database_update is fired when the delta is parsed, which causes
the current view to be redispatched and updated, ending the drag event.
5.  You're left moving your mouse around wondering what's wrong.

What to look for in the console:

Env: send msg 4
{"op":"update_annotations","entity":"wordpress","data":{"gui.x":159.83539268580273,"gui.y":60.97466861126179},"request_id":4}

    // The update_annotations call from dragend
Env: Receive {"log": [], "result": true, "request_id": 4, "op":
"update_annotations", "data": {"gui.x": 159.83539268580273, "gui.y":
60.97466861126179}, "entity": "wordpress"}
    // the result response from juju
...
D3 Handler for .service mousedown.addrel
    // You've started dragging the second service
Env: Receive {"result": [["service", "change", {"gui.x":
159.83539268580273, "gui.y": 60.97466861126179, "charm":
"cs:precise/wordpress-7", "id": "wordpress"}]], "op": "delta"}
    // The delta with the updated annotations sent to all listeners
Env: Dispatch Evt delta
    // Env. view is redispatched.
Env: send msg 5
{"op":"update_annotations","entity":"mediawiki","data":{"gui.x":427.7225324503131,"gui.y":620.9746686112618},"request_id":5}

    // The dispatch causes you to drop the second service.
    // It is subsequently updated.
Env: Receive {"log": [], "result": true, "request_id": 5, "op":
"update_annotations", "data": {"gui.x": 427.7225324503131, "gui.y":
620.9746686112618}, "entity": "mediawiki"}
Env: Receive {"result": [["service", "change", {"charm":
"cs:precise/wordpress-7", "id": "wordpress"}], ["service", "change",
{"gui.x": 427.7225324503131, "gui.y": 620.9746686112618, "charm":
"cs:precise/mediawiki-3", "id": "mediawiki"}]], "op": "delta"}
    // Things get a little weird here, because we're receiving a delta
    // for both the first and second service (but the first has no
    // actual content updated).

It goes on for a little while after that, and it's easy to start seeing
what's happening when with the folded Delta console logs.  I get the
feeling that this isn't limited to annotations, however, and that any
delta coming in while you're dragging a service around will cause the
same behavior (I've not tested this, but I'm 99 and 44/100ths percent
sure it would be the case).

Some ideas:

Annotation deltas come back as service changes.  It could be that the
environment view needs to handle updates a little more intelligently,
which means we would need to switch from this.dispatch() to something
else in app/app.js:348.  If the current view can be updated rather than
redispatched, there's a chance that the update method on the environment
view could work with simply updating itself without interrupting any
in-progress events.

Part of this, of course, depends on Ben's current branch of maintaining
service positions.  While this might fix the update on annotations,
there's no guarantee that it will fix other deltas that will cause a
redispatch while the user's doing something.  Even so, in those cases,
maybe we do want to cancel the current event (what if a delta was
received deleting that service?  We wouldn't want to put that on hold so
that they can drop it and get an error on update_annotations).  It's
something worth discussion.  All the same, I'd recommend[2] perhaps
moving to something other than this.dispatch(), which is a bit
heavy-handed if we've got less intense deltas coming in now.

Cheers,

~M

[1] https://bugs.launchpad.net/juju-gui/+bug/1099921
[2] I'll be around on email, especially on travel days, where we
intentionally have nothing planned.