The draggable comment regions, introduced in 2.5, had some visual,

performance, and feature regression bugs.
When dragging a comment region, its tooltip would stay on the page,

getting in the way (visually) of the drag. It's now hidden during drag.
While dragging, every mousemove event resulted in a new GET and PUT

request to the server, re-fetching the comment data and updating it.

This caused some massive slowdown and was hard on the server. Turns out

we didn't need to do this at all during drag, since we finalize the drag

by saving out the state to the server one last time. We now leave it up

to this.
Due to the dragging problem, and the order in which we got responses

back, we could end up saving wrong coordinates out when finalizing a

drag, meaning the region wouldn't be where the user thought it was. We

now set the expected coordinates on the comment model right when we're

ready to save.
The new event handling for mouse and click events broke clicking on

comment blocks for PDFs. It wasn't possible to see existing comments or

to edit draft comments. This was partially due to a bad use of _super()

in the view's prototype, and some broken logic further down. It wasn't

apparent with images, because images have some of their own event

handling that worked around some of this. For the common case (which

impacts PDFs), this logic has been reworked to be more reliable.
There were also a handful of small things in the code.

Some methods/member variables exposed as public that should have been

private, and some function ordering issues. These have been fixed up.

Tested moving and resizing comment blocks for images, and moving them

for PDFs (as resizing isn't yet supported).
Saw that the new state saved with the expected coordinates. Verified this

on page load.
Tested clicking comments to see/edit the comment text and to see the

other published comments associated with the region.
Saw that the tooltip disappeared when dragging the comment region on PDFs

and images.