Sometimes single clicks are not processed

[ftvkyo]

main.lua

love["mousereleased"] = function(x, y, button, istouch, presses)
    print("mousereleased")
end

love["mousepressed"] = function(x, y, button, istouch, presses)
    print("mousepressed")
end

Video: https://www.youtube.com/watch?v=4YGjKoG2H8w (may delete someday)

Behaviour:
On some game runs, Love processes only double clicks, single clicks won't work. Everything is back to normal after game restart.
Usually, it takes a lot of game restarts to reproduce the problem.

Expected behaviour:
Love always correctly processes single clicks.

Software:

• Love 11.3 from brew
• macOS 10.15.5 (19F101)

Hardware:

• MacBook Pro (16-inch, 2019)
• Trackpad and mouse

I can provide additional info if needed.
I will also try to reproduce the problem with less software running as @slime73 suggested. There may be some third-party software interfering.

[slime73]

Does this happen with the official 11.3 macOS app (available here)? We can't really guarantee that software built using brew or other package managers is using the same dependencies LÖVE was tested with.

[slime73]

For now I'm assuming it doesn't happen with the official app, but let me know if that's not true.

[Koloth]

I have this issue on the official release of 11.4a. It seems to correlate with program complexity (maybe frame rate) somehow, so as I develop, the probability of it happening increases. MacOS 12.5.1 (21G83), M1 MacBook Pro 14-inch, 2021. Official release Love 11.4a. The same behavior where single clicks, on some launches, do not register, but do register with double clicks.

[slime73]

Are you using love.mousepressed, or love.mouse.isDown? Also do you have any changes to the default love.run?

If you have some code or a .love that reproduces the issue for you that will help too.

[Koloth]

I'm using love.mousepressed with no changes to love.run. The below code snippet reliably reproduces the error for me (In 8 sequential trials, it entered the "double click only" mode in 3 instances --- video available of those 8 trials if helpful, but it is just me pressing run in vs code and trying to click). I'm not sure the InitLoops are needed (although it might make it less likely), but it seems the other three are, and also the indirection where the mouse click is passed on to a handler function inside a table is. Moving the function out of the table makes it very unlikely to enter the mode on my machine (<1/20 estimated probability). As the OP showed though, it can happen by random chance with even the smallest of test programs, but you need something more substantial to get the error rate high enough to observe.

-- This code enters the broken mode for me about 3 out 8 trials.

InitLoops = 10000000
UpdateLoops = 10000000
DrawLoops = 10000000
ClickLoops = 10000000

Clicked = false

function love.load()
    love.window.setMode( 1280,720, {highdpi = true})

    local dummy = 0
    for i = 1,InitLoops do
        dummy = dummy*dummy
    end
end

function love.update(dt)
    local dummy = 0
    for i = 1,UpdateLoops do
        dummy = dummy*dummy
    end
end

function love.draw()
    local dummy = 0
    for i = 1,DrawLoops do
        dummy = dummy*dummy
    end
    love.graphics.print("Click Detected: " .. tostring(Clicked))
end

function love.mousepressed( x, y, button, istouch, presses )
    local dummy = 0
    for i = 1,ClickLoops do
        dummy = dummy*dummy
    end
    Dummy:indirection()
end

Dummy = {}

function Dummy:indirection()
    local dummy = 0
    for i = 1,ClickLoops do
        dummy = dummy*dummy
    end
    Clicked = true
end

I will also say it is device/os dependent. I have a significantly more complex game I'm working on that enters this strange mode nearly half the time on my development machine, but the actual targeted device is an iPhone, and I've never had this problem with the same code run on Love on the iPhone.

[Koloth]

Ok, I decided to just toss up the video of the trials anyway here. This was recorded with Quicktime on my Mac with "show clicks" on, so my mouse cursor is surrounded with a circle each time I click the mouse. in 3 out of 8 trials in this recording it enters the mode where single clicking fails, but double clicking works -- hopefully reliable enough that someone else can repro!

[slime73]

Thanks for the test code. I ran it 20 times on my laptop (x64 Macbook Pro from 2016, macOS 12.6) and haven't been able to reproduce it there. I'll try on an M1 machine later.

[slime73]

I ran the test code a bunch of times on my M1 mac with both macOS 12.1 and macOS 13.1 and wasn't able to reproduce it there either. I wonder if some third-party software is interfering.

I also noticed in your video that when it doesn't work, the window hasn't been fully focused (the close/minimize/maximize window buttons are greyed out whereas they have full colour in the tests where it does work). I suppose whatever is causing the issue is preventing the window from fully foregrounding itself or something.

[Koloth]

I ran additional testing and that is indeed the issue somehow. I've been able to get it out of the inoperable mode by minimizing then maximizing the window which then grants it full focus. Without additional evidence to the contrary, I think this has to be something third-party capturing the focus (although it happens with no other apps and it depends on the code being executed...). Thanks for working through this!

[kristinalustig]

I know this issue is closed, but @Koloth I found that this issue only happens when the game is starting up and I move my mouse. Who knows why, but I fix it by just not moving my mouse while the game is compiling before it loads. 😅 I wonder if it could have something to do with the IDE you're using? I'm using ZeroBrane Studio and I notice it does weird things with mouse focus sometimes.

[pherrymason]

Just to add to the conversation, I've experienced this very same issue with my Mac M1.
Surprisingly, not using Love2d, but with other libs in rust (macroquad): not-fl3/macroquad#422

Exactly the same: only double clicks being processed, and the same issue with the window being unfocused.

Maybe the issue comes from a dependency?

[Koloth]

@pherrymason What IDE are you using? I’ve come to be of the opinion that, for me, it is somehow VS Code taking back focus while the app is launching. This makes it code dependent (since it depends on the code launching time). Watching my own video back again, it does indeed look like I reach for the mouse earlier in those cases where the failure happens.

So perhaps: something all these cases is doing leads to the original launching app retaking some of the focus. Problem is we have two different IDEs, or direct from the command line launching love2d or rust. This feels like something OS level to me.

Very interesting.

[Koloth]

Thinking through it more: I guess what is happening in all these cases is that after the app launches, but before the window is created, a mouse event needs to be handled. This mouse event is sent to whatever is doing the launching which then puts the newly created window into a half-focused state, where clicking doesn’t grant the window focus, but it also doesn’t get the mouse click event (unless it is a double click???). There are still some mysteries here to be sure.

In any case, I don’t think there is anything to do on the love2d side to fix it.

[pherrymason]

I'm more inclined to think this is a OS bug, seeing the same issue being suffered across different projects on github:

• App window does not respond to mouse events in window focus race condition cypress-io/cypress#21743
• [Bug]: Launched app from Electron is not correctly focused electron/electron#36506
• Input issues on macOS when running binary directly instead of .app bundle godotengine/godot#8653 <- Here they seem to deep into the issue more
• First mouse click is ignored / does not work godotengine/godot#8907

[pherrymason]

Noticed the following, looks like Defold had the same issue and looks like they fixed it: defold/defold#7949