Hi, this is strange behavior. some questions.

• Does this happen on every curve? (try spot lamp falloff curve for example... or texture painting falloff curve)
• Does this happen after resetting to factory defaults?
• If you have access to another system, can you redo the bug elsewhere?
• Are you using any kind of special/non-standard input software/drivers. (we had reports that blender fails with http://smoothmouse.com for eg).

• This seems like it happens on every curve

https://dl.dropboxusercontent.com/u/55113627/%3E%20Blender/test-RGBCurvesNode.mov

• I tested on factory setting
• Same behavior on other two iMacs. I don't have another OS like Linux or Windows, but from your reaction I see you don't have this issue.

(iMac 27" OS X Yosemitte 10.10.3 ATI Radeon HD 5750 1024 MB and iMac 24" OS X 10.8.5 ATI Radeon HD 2600 Pro 256 MB)

• I don't use any "non-standard" inputs, I use only Wacom tablet, but the as I wrote - same behavior is on iMacs without any special inputs.

Now noticed one more think (see video) when I move slider, then on mouse release pointer appears on first click position - as with curve manipulation, and in this case it looks helpful - we don't have to move back pointer into slider area, and that is why I didn't post it earlier as a bug.
But small problem here is - if I click again (to move slider) without any mouse pointer movement, than node jumps :) If I move (even a bit) mouse pointer it doesn't happen. https://dl.dropboxusercontent.com/u/55113627/%3E%20Blender/test-Slider.mov

Here is a behavior in 2.63 for reference. Pointer stay at a point of release (curve or slider).
https://dl.dropboxusercontent.com/u/55113627/%3E%20Blender/test-263.mov

Somethink that maybe helps identify error:
I use Screenflow for recording, in this app I can activate "Click effect" on mouse click.
In videos you can see - click effect is not there for clicks with mentioned issues, but visible in test in 2.63 where it works. So also this app see differences with mouse click to move node and move curve.

So far seems nobody cant reproduce..

@Thomas Dinges (dingto), @Martijn Berger (juicyfruit): do you mind trying your luck reproducing the issue?

Nobody with OS X can't reproduce this?

My wife notebook MacBook Pro, OS X Yosemite 10.10.2, Intel HD Graphics 4000 1024 MB.
It is the fourth Mac with this issue.

I can reproduce on macbook pro with iris pro.

@Bastien Montagne (mont29), thought @Martijn Berger (juicyfruit) managed to reproduce the issue?

Arg! sorry, read 'can’t' instead of 'can' :(

This option is broken on Macs since the beginning. Mouse warping or hiding is against the Apple UI guidelines, which is why it works so bad I guess.

How did the OSX team here accept it? Easy to see how broken it is:

• get a panel with 2 number buttons next to each other
• drag value of left button to right, move mouse on virtual position of the other button. you see it hilight.
• release mouse, click. Input goes to the wrong button.

I'm in agreement with OS X guidelines, and against manipulating mouse positions. Nice for some people, but then only behind a user pref.
Why is it bad? It kills muscle memory, it makes you lift up the mouse all the time to put it back. So in the end you don't even win anything (as in speed of use).
I can see why some like it though, especially if you navigate around with a mouse-lift habit.

@Ton Roosendaal (ton),

• There's no wrapping/mouse position manipulation involved in this particular case. If OSX can not survive hiding the mouse cursor then well....
• This _is_ and option, which is called "Continuous Grab" (User Preferences -> Input -> Continuous Grab). It was enabled by default quite some time ago. Discussion about whether it was right or wrong decision is a separate topic, this report clearly shows a bug which is to be addressed.

EDIT, well actually it might be wrapping when shift is holded down. Not sure if any wrapping happens without shift tho.

Sergey: in contrary. It wraps the mouse in this case too (and it fails to).

Sorry, seems like my english skills are not enough to clearly understand the discussion now, so only one note to ton's post "This option is broken on Macs since the beginning." - as mentioned in the bug description - it worked well in 2.63 and older versions on Mac.

@filip mond (vklidu), this is maybe caused by the default activated Continuous Grab and the Update in 2.66 (see Release Notes). You can deactivate it in the preferences (Input Tab)

@Leon Eckardt (Leon95): Thank you. You are right, disabled "Continuous Grab" keeps cursor behaviour OK.
But "Continuous Grab" is super useful thing ... any chance to find solution?

If its because of continuous then it is known todo any reason we are keeping this open as a bug a not a to do?

@Aaron Carlisle (Blendify), this is not the same as continuous grab issue, even when continuous grab is working properly (for view-port operations) this glitch still happens.

Fixed both the original reported issues with curves and the button focus issue explained by Ton.

The main issue is that contrary to what the comment in the code said, the cursor position must be set again when continuous grab ends, the same as on other platforms. Most of the changes are fixing some inconsistencies in coordinate space conversion to make that work.

I know it is not a chat here, but I have to say ... Thank you million times for this fix :)