Handoff of service dragging defect

[Gary Poster]

Thank you, Matt!

Everyone else, to be super clear, this is a request to please take over this bug from Matt, who will be back next Wednesday. Brad's bug also will hopefully get someone else to run with it, though he is back tomorrow. 

Gary

On Jan 16, 2013, at 8:52 PM, Matthew Scott <matthew.scott at canonical.com> wrote:

> 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.
> 
> -- 
> Juju-GUI mailing list
> Juju-GUI at lists.ubuntu.com
> Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-gui