Input issues on macOS when running binary directly instead of .app bundle

[BastiaanOlij]

Operating system or device - Godot version:
Godot 3.0
Mac OS X 10.12

Issue description:
Single click no longer functions, seem to be ignored. Double clicks still work though
Was working fine in the build from a few days ago, but stopped working after a fresh build of master yesterday.

Steps to reproduce:
Click on something :)

[akien-mga]

Was working fine in the build from a few days ago, but stopped working after a fresh build of master yesterday.

Do you know how many days ago? I don't see any relevant commit in the last 7 days.

[BastiaanOlij]

Hmmm, no I don't actually, I've been mostly working with Godot 3 on Windows, and Godot 2 on my Mac, so I'm not clear about how long ago I did anything serious on the Mac side.

[BastiaanOlij]

Weird, I did a completely clean build, and it seems to work now... I'm off to bed and I'll test some more tomorrow. if it keeps working I'm going to close this and write it off as a linker issue :)

[vladpazych]

In Godot 2 it happens sometimes with version I compiled from source (2.1 branch)
It's fixing itself when you unfocus Godot window by clicking somewhere outside, and then return back.

[BastiaanOlij]

@vladpazych must be something similar, its been behaving all morning, I'm going to close this.

[toger5]

just want to mention I have the same issue from time to time. (also osx)
I will write again when I see any kind of pattern when it does not work.

[ArdaE]

I'm having the same issue on macOS (formerly OS X) using Godot 3. Most of the time a single click works, but occasionally double-click is required. This applies to both the Godot UI and apps created with it. Just now, an app I built had the same problem 3-4 times within the span of a few minutes (each after a restart of the app). When the app first starts, there's a chance it may need 2 clicks to operate everything (buttons, etc.). If the problem is there on app startup, it never seems to go away until another restart. And if it's not there on startup, then it never seems to appear later on (so this seems to be a lottery at app start). However, after several more restarts of the app, I can't reproduce the problem anymore (nothing changed in the app at all).

I experienced this issue with the Godot UI itself last week after I upgraded to Godot 3, which initially made me think that the team had changed the UI behaviour. After a few restarts, it started working fine.

It may be worthwhile to reopen this issue. Although it's a rare issue and a restart fixes it, it is a serious issue as it affects the generated apps.

[ArdaE]

Found a way to reproduce this bug very easily. Simply keep moving the mouse while a Godot app is starting. It doesn't matter if the app is the Godot Project Manager, Godot editor, or a Godot game you create. If the mouse is moving during app launch, then the started Godot app never gets the focus and requires a double-click for everything.

A quick debug sessions shows that if the window doesn't have the focus, LMouseDown events are still received just fine by GodotApplication's sendEvent method (implemented in "os_osx.mm"), which then calls "[super sendEvent:event]" correctly (same as when the window has focus), but then [super sendEvent:event] never calls GodotContentView's mouseDown method for single clicks if the window does not have the focus. Interestingly, double-click events are routed just fine, which is why double click works as the title of this issue states. So the issue is in os_osx.mm, not the platform-independent portions of the Godot engine. The solution will likely involve ensuring that a newly started Godot app's window has the focus even if the mouse is moved during launch (as an end user cannot be expected to not move the mouse when starting a game). [Observed on macOS Sierra, 10.12.6].

Please re-open this issue, as it is real, reproducible, and affects created (end-user) apps.

[bruvzg]

@ArdaE Focus problem on start may be related to #8907.

May be also related with a way Godot launch child processes (using executable path directly).

[ArdaE]

@bruvzg Yes, following the instructions listed under #8907 fixed the issue. So this becomes a documentation issue then. The following line at http://docs.godotengine.org/en/latest/development/cpp/configuring_an_ide.html#scheme-setup

ln -f ${PROJECT_DIR}/bin/godot.osx.tools.64 ${PROJECT_DIR}/bin/godot

should be replaced with

cp -r ${PROJECT_DIR}/misc/dist/osx_tools.app ${PROJECT_DIR}/Godot.app
mkdir -p ${PROJECT_DIR}/Godot.app/Contents/MacOS
cp ${PROJECT_DIR}/bin/godot.osx.tools.64 ${PROJECT_DIR}/Godot.app/Contents/MacOS/Godot
chmod +x ${PROJECT_DIR}/Godot.app/Contents/MacOS/Godot

and the "Executable" in the screenshot that follows should be set to "Godot.app" instead of "godot".

If one is generating an optimized and/or fat binary, then the above instructions would need to be modified for those, but considering the earlier instructions on the same page are for a 64-bit debug version, the above change should do the trick.

By the way, this change fixed the issue on all fronts: Godot Project Manager, Godot Engine Editor launched by Godot Project Manager, and Godot apps/games launched by Godot Engine Editor all work fine once Godot.app is in an app bundle. Thanks for linking that other issue.

[BastiaanOlij]

Hmmm, I got to try this out a bit more at home. So if I understand correctly the problem only happens when you start the godot executable directly from terminal? I started doing that because it allows me to see better output then when starting it as an app (prints to the console).

Also for my development app I'm symlinking the godot executable in the app bundle to the compiled one in my bin folder. It'll be interesting to see if that makes a difference.

To be continued.... :)

[bruvzg]

For me symlinking works for process started manualy, but child processes still have focus problem (opening project from Project Manager or running project), probably Godot resolves real executable path for symlink.

Starting bundled executable from terminal (like ./Godot.app/Contents/MacOS/Godot) seems ok.

[akien-mga]

AFAIU it only affects running the binary directly (typically when self-compiling) and not via the app bundle. Since official binaries are released as app bundles, it should not be critical for 3.0 I guess.

[ArdaE]

Because the documentation also describes how to build Godot from source code, I think this should be fixed in the documentation as I outlined above. No need to waste people's time for what can be fixed by changing 1 line of documentation.

@BastiaanOlij, in my case the issue was happening when I start Godot via Xcode, in debug mode so Xcode's debugger is attached, not manually from the terminal.

[BastiaanOlij]

ArdaE, hmm I still haven't got it running in XCode. XCode can be told to run the app instead of the executable as well.

What I've noticed when I was debugging and fixing the code that loads the project at startup is that when you run the executable directly its run with a much broader environment. It's like it runs it inside of a bash shell or something. When starting it as an app its a much more limited scope, much more sandboxed. No idea if that has anything to do with this issue.

[ArdaE]

@BastiaanOlij, yes, Xcode can definitely be configured to run the .app version, which fixes the issue. See my earlier comment above for the documentation page for configuring Xcode and how the page should be modified to get Xcode to both generate and run a .app version of Godot (search for the word "screenshot" in this thread).

P.S. I highly recommend using Xcode to launch Godot. That makes debugging the engine code so much easier. Once again, this issue is a documentation issue, not a code issue at this point.

[CodeAndWeb]

I can reproduce this issue on my Mac from QtCreator:

• start the binary in debug mode with -e --path / ...
• resize the main window as soon as it appears

I've also debugged the issue: MacOS is sending the events to GodotApplication::sendEvent. They are not completely missing... but seem to get lost during [super sendEvent:event]