Wouldn't really consider this is a bug, more like a specific of how warping works for continuous grab. It could be improved by seeing "aha, cursor is leaving the window so let's transwarp beam cursor back to the window". But that's kind of arbitrary and could break stuff like focus change and so.

@Brecht Van Lommel (brecht), any thoughts?

Not really, @Campbell Barton (campbellbarton) created this continuous grab system, he might know.

As far as I can see, the issue occurs when the mouse is moved quickly and escapes the boundaries of the blender window, so that when it's teleported to the other size, it comes with an extra (perhaps double?) translation.

It could possibly be solved by having the cursor teleport to the opposite side before actually reaching the edge of the window, perhaps even something so much as 50 pixels from the border, since the border is actually irrelevant during an operation with continuous grab.

This is because X11-Grab isn't being used at the moment.
https://developer.blender.org/diffusion/B/browse/master/intern/ghost/intern/GHOST_WindowX11.cpp$76

Using the OS's grab is nice, but I disabled it because it could lock X11 (no easy way to ungrab unless you know to Ctrl+Alt+FKey to login to a shell & kill the application grabbing the cursor).
See: rB3e3d2b7a4cfc38f673bdeb48707b95c7bd50049a

Since Blender is more stable now we could enable again.

set as todo: see http://wiki.blender.org/index.php/Dev:2.5/Source/Development/Todo/UserInterface#Mouse_Support

If its possible to drag the subsurf levels up to a high value without locking the OS (where most users would have to hard-reboot), then cursor grabbing can be enabled again.

One common solution to this problem is to do continuous grab by hiding the mouse and continually re-positioning the mouse to the center of the application window.

This way, no matter where the mouse was when the grab was started, it's pretty unlikely to leave the window in between runs of the event loop. When the grab is done, the mouse is returned to its original location and shown again.

Right, we do this already for number-button editing (constrain to a very small area at least).

We could do this for all wrapped mouse-cursor usage, but it is nice to have some kind of cursor on the screen.

A solution could be to draw a fake cursor, but internally to the location resetting trick.

What I find strange is that the cursor warp used while rotating the view seems unbreakable.
Even if the cursor is moving fast enough to be briefly drawn far outside the window, blender warps it back no problem.
Only translations seem to allow the cursor to escape in this manner.

What's different about the view-rotate cursor warp?

Is this issue still present? Wasn't this fixed in rBd6fd03616ec2

@Yevgeny Makarov (jenkm) the linked issue is for redundant wrap accumulation, thus objects move off screen. This issue is about cursor escape.

@Kitt Zwovic (gandalf3) the likely reason is computation time difference between operators (including side effects). A faster operator is likely to either have fewer coalesced mouse events, thus more likely to catch it in the "warp zone" since cursor moves outside of the window are not handled.