I am not able to reproduce this issue. Tested Safari, Firefox, Chrome all on Yosemite. Is there anything obvious in the developer console?

I just replicated it again. Typically what occurs is after a few drags upon drop a Task box freezes in "selected" state (e.g. darker grey) and then no more boxes can be dragged.

The first few times I ran into it it happened within about 5 drags, but it can also take much longer.

There seems to be some kind of interaction with tab and focus changing as well. It feels as though the freeze occurs more quickly when moving between tabs.

It sort of feels like the "grey" state is when the workboard is waiting on the server to update the new list position. It could be that it's timing out or otherwise failing on my computer right now. I haven't yet been able to replicate it with developer console open—I don't yet see anything weird.

Yup, here's how you replicate

1. Go to a workboard, any workboard
2. Kill your wifi connection (assuming that's how you connect to the internet)
3. Drag, drop, see the UI freeze forever
4. Witness the following in the dev console:

Failed to load resource: A server with the specified hostname could not be found.

After D20305, this can be "fixed" with this change:

diff --git a/webroot/rsrc/js/application/projects/WorkboardBoard.js b/webroot/rsrc/js/application/projects/WorkboardBoard.js
index a7786a86f..6c4580766 100644
--- a/webroot/rsrc/js/application/projects/WorkboardBoard.js
+++ b/webroot/rsrc/js/application/projects/WorkboardBoard.js
@@ -498,10 +498,13 @@ JX.install('WorkboardBoard', {
         dst_phid,
         data.afterPHID);
 
-      new JX.Workflow(this.getController().getMoveURI(), data)
+      var workflow = new JX.Workflow(this.getController().getMoveURI(), data)
         .setHandler(onupdate)
-        .setCloseHandler(on_revert)
-        .start();
+        .setCloseHandler(on_revert);
+
+      workflow.listen('error', on_revert);
+
+      workflow.start();
     },
 
     _revertCard: function(list, item, src_phid, dst_phid) {

However, this just makes the card jump back to its original position, which isn't necessarily any better or less confusing than freezing the card at the end of the drop. When the board is frozen, you're at least likely to try reloading and probably hit the connectivity error, explaining the issue. When the card jumps back, it feels more like everything is "working" but you're hitting a bug, and I'd guess users are less likely to reload the page and discover the root cause.

We don't currently have graceful client-side support for communicating states like connection interruptions to the user. Presumably we will some day, but until then I think the current behavior is slightly less bad than "fixing" this.