FS#4392 - [OSX] Cursor "jumps" at borders of window

Attached to Project: OpenTTD
Opened by Roger F (rdoger6424) - Saturday, 08 January 2011, 17:53 GMT
Last edited by Michael Lutz (michi_cc) - Monday, 05 August 2013, 20:40 GMT
Type Bug
Category Interface
Status Closed
Assigned To No-one
Operating System Mac OS X
Severity Medium
Priority Normal
Reported Version 1.1.0-beta2
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 1
Private No


When I play in windowed mode on my mac (OS X 10.6.5), the cursor seems to "jump" when I am close to the left edge of the window, and seems to "stick" when I am on the right edge.
The distance seems to vary proportional to the distance the window is from the left edge of the screen (so this does not happen if the window is all the way to the left side of the screen (for moving into the window horizontally), and/or all the way to the top (for moving in vertically)).
When the window is in the middle of my screen, when I move into the openttd window from the top, my cursor moves to the right as it enters the screen.
I know that I'm not explaining this well enough, so feel free to ask for clarification.
This task depends upon

Closed by  Michael Lutz (michi_cc)
Monday, 05 August 2013, 20:40 GMT
Reason for closing:  Fixed
Additional comments about closing:  In r25658.
Comment by Ingo von Borstel (planetmaker) - Saturday, 08 January 2011, 18:45 GMT
  • Field changed: Summary (Cursor "jumps" at borders of window (Mac) → [OS x] Cursor "jumps" at borders of window)
  • Field changed: Operating System (All → Mac OS X)
Does that happen only under certain conditions, like when moving 'into' the window from the all-windows overview? Or always? Did you compile yourself or do you use the one found on our website?

And: how big are these jumps. Is there a relation of the jump to the right wrt the left border of the window to the screen's left border? Same thing with the jump in vertical direction: a relation between the jump length and the upper or window position wrt the screen's upper border?
Comment by Roger F (rdoger6424) - Saturday, 08 January 2011, 19:30 GMT
The thing that triggers this is whenever I move the mouse down into the window (i.e. from the top of the screen into the window). If completely refrain from crossing the top window boundary, it works fine, even if I move the window further to the right / bottom. Going into any of the exposé modes, and then back into the window does not trigger the problem.
I downloaded and used the dmg file on the website.
There is a 1:1 relation between the gap between the window and left edge of the screen and the "no-go-zone" on the left edge of the window.
Comment by Remko Bijker (Rubidium) - Saturday, 22 January 2011, 16:43 GMT
Given there was a significant rework of lots of Mac OS X handling of the video backend it might been introduced by that rework. To be sure I'd like to know whether you can reproduce it with the nightly before that rework, and if so whether you can with the nightly after the rework.

So, can you reproduce this issue with the r21546 nightly? You can find it at
If you can't, can you reproduce it with the r21588 nightly? You can find it at
Comment by Remko Bijker (Rubidium) - Sunday, 27 February 2011, 10:27 GMT
It would be helpful if you could perform the tests I suggested relatively quickly as those nightlies are about to be removed from the binaries server.
Comment by Roger F (rdoger6424) - Sunday, 27 February 2011, 10:42 GMT
Unfortunately, I can't do the tests, as I am away from my mac and will be for quite some time.
Comment by Lee (leecbaker) - Monday, 05 September 2011, 03:29 GMT
I can for sure reproduce this bug on latest trunk (r22893). I'll have a look at this in a day or two- I've recently been looking at the OS X video code in the cocoa/ folder, and suspect there may be an issue with the conversion from screen coordinates to window coordinates.
Comment by Roger F (rdoger6424) - Monday, 05 September 2011, 05:36 GMT
It happens on the latest stable as well. I have not tried with lion yet, only with Snow Leopard.

Thank you for reminding me of this bug. I was out of the country for a few months.

Should I update the version or keep it at 1.1.0-beta2?
Comment by Lee (leecbaker) - Monday, 05 September 2011, 07:36 GMT
Steps to reproduce 4392:

* Run OpenTTD (main menu appears)
* Move window position to 100px right of left edge of screen. Put mouse on left edge of screen.
* Move mouse right 150px, so it is 50px within the OTTD window. BUG: cursor is drawn 150px from the window edge (250px from the screen edge), instead of 50px from the window edge.
* Click mouse within window. Mouse cursor will jump to correct position until the cursor is moved outside the window again.

I'm using 10.7, with r22893.

What appears to be going on:
At, locationInWindow is used to convert from window coordinates to view coordinates. When the mouse is moved outside the window, the MouseMoved event quits targeting the OTTD window (and [event window] becomes nil). The window is provided with screen coordinates instead of window coordinates. This is mentioned in the NSEvent locationFromWindow documentation:

"With NSMouseMoved and possibly other events, the receiver can have a nil window (that is, window returns nil). In this case, locationInWindow returns the event location in screen coordinates."

This wouldn't be a problem (the cursor is only needed when the mouse is positioned inside the window), but the mouse moved event doesn't target the window again until it is clicked on.

At this point, my Cocoa-foo isn't strong enough to know how to fix this. From the documentation, I can't figure out how you get to the state where the NSEvent has a nil window. It obviously happens when the mouse leaves the window, and returns when you click inside the window; is this something that OTTD is doing, or is it a Cocoa thing?
Comment by Ingo von Borstel (planetmaker) - Monday, 05 September 2011, 08:22 GMT
Might be related to mode switches (fullscreen, window, (un)hide) where in the first two cases the driver is re-initialized and in the second the focus regained or given away
Comment by Brandon (brandonr) - Tuesday, 24 January 2012, 01:45 GMT
I am able to duplicate this issue using OS X 10.5.8 in the current revision (r23826).
Comment by Soul Fairer (soulfairer) - Sunday, 11 November 2012, 16:15 GMT

I've changed the quartz code for the mouse position. Now it seems to work, both in fullscreen and windowed mode (for fullscreen: pointer position is consistent when menu shows).

My two cents for this marvelous project!
Comment by Soul Fairer (soulfairer) - Sunday, 11 November 2012, 23:21 GMT
diff -u for this as pointed out by Michael Lutz!
(please disregard patch 2 - I haven't used diff for years!)
Comment by Ingo von Borstel (planetmaker) - Wednesday, 14 November 2012, 22:05 GMT
I'm afraid that this patch doesn't solve the issue for me. On the contrary, it introduces further complications:
- When I move the cursor into the window it disappears under certain conditions.
- The cursor still jumps: use a window for OpenTTD. Drag the window to another place. Move the cursor somewhere else, not into the openttd window. Move back to the openttd window. You see the cursor nicely jumping when entering the window
- Even worse: the cursor disappears also frequently when click anywhere on the title screen. It re-appears when I move the mouse, but I have a very hard time to select anything. It seems that cursor and mouse coordinates differ with this patch by as mutch as the window is offset wrt desktop origin.

As much as I'd like this issue see fixed: I'm afraid that this patch makes the mouse behaviour quite a bit worse for me (OSX 10.6.8).
Comment by Soul Fairer (soulfairer) - Sunday, 25 November 2012, 00:00 GMT
For me (OSX 10.8) it worked. Can someone test it also in OSX? I don't have access to a 10.6.x machine, will install a VM.
Comment by Grow (Matthieu) - Sunday, 03 February 2013, 17:56 GMT
I think my patch will solve all the problems. I'm on osx 10.8.2 and some test have to be made on osx < 10.7. Thanks in advance.
Comment by Michael Lutz (michi_cc) - Monday, 04 February 2013, 18:00 GMT
You do realize that MAC_OS_X_VERSION_MAX_ALLOWED only describes which SDK is used to compile OTTD, right? You probably want IsMacOSVersionAtLeast instead. What happens if convertRectFromScreen is called on e.g. 10.5?

The compile farm builds OpenTTD with the 10.5 SDK and upgrading is difficult as we'd need a new cross-compiler, which means the new code path wouldn't be used anyway. Maybe this could be worked around by fudging with performSelector.
Comment by Grow (Matthieu) - Friday, 08 February 2013, 13:31 GMT
Ok, i've read some documentation about weak linking and i think i've understood what do you mean.
Comment by Michael Lutz (michi_cc) - Friday, 08 February 2013, 15:40 GMT
Is it necessary to call convertRectFromScreen on 10.7 or later because e.g. convertScreenToBase doesn't work anymore? If yes, we have a problem because MAC_OS_X_VERSION_MAX_ALLOWED will be MAC_OS_X_VERSION_10_5 on our compile farm. If not (which I think is true, as the docs only say deprecated, not removed), the code is almost good in theory. It's missing some {} around the if statements, see

No 10.7 to test available, so I can't say anything about whether it works in reality and fixes the bug. I do believe however that it should be "@selector(convertRectFromScreen:)" (i.e. just one : ).
Comment by Grow (Matthieu) - Saturday, 16 February 2013, 08:52 GMT

I think it's necessary as that's the new way to do things on OSX. That's the coding convention on that platform. See Apple guidelines or look at the informations on

I think that's not a problem if the project is compiled againts 10.5 sdk.
- There is some other code that depends on 10.7 sdk;
- Later the projects might be built on 10.7 sdk;
- It runs on my osx 10.8.

I added curly brackets for if statements in the joined patch.

What does mean "waiting on reporter" status? I don't speak a very good english and i'm not sure. Does it mean we must wait on the bug creator (Roger F) to test, approve and add to trunk the patch ?
Comment by Michael Lutz (michi_cc) - Tuesday, 19 February 2013, 22:34 GMT
> I think it's necessary as that's the new way to do things on OSX.

With necessary I really meant absolutely necessary, i.e. does convertScreenToBase:fromView: fail on 10.7? I don't care if some Apple docs mark that as obsolete as long as it still works. Our compile farm will not get anything else than the 10.5 SDK in the foreseeable future, so our offical binaries will always use convertScreenToBase: and never convertRectFromScreen:. It's still good to have both ways in the code for those that compile themselves (and in case we ever do get a new cross compiler). The patch itself looks good.

> What does mean "waiting on reporter" status?

Ideally we would indeed hear from the original reporter. Often enough this is not possible or feasible, but it would still be nice to get a confirmation from somebody else, especially as past experience with OS X bugs has often shown very different results on different system combinations.
Comment by Grow (Matthieu) - Sunday, 24 February 2013, 08:45 GMT
Ok, Thanks. Waiting for the reporter.
Comment by Michael Lutz (michi_cc) - Monday, 25 February 2013, 16:30 GMT
I made a binary with the same setup as our compile farm at, could you test if that solves the problem? Please note that it is *completely* untested by me.
Comment by Grow (Matthieu) - Monday, 25 February 2013, 21:23 GMT
Ok, i tested it on my osx 10.8.2. There was no "jumping" problem using it.