openfl.utils.Timer Stops Abruptly

[devsena]

Describe the bug

I started running openfl.utils.Timer which runs in a given interval - the output platform was cpp/macOS.

While the TimerEvent.TIMER ticks fine as long as the application is running AND macOS system is wake. Minimise the application, lock/sleep the macOS system. Return after a few minutes and wake the system.

We can see that the TimerEvent.TIMER ticks entire period when the system was locked, which was great; But the timer abruptly stops as soon as system waked or unlocked - Bug.

To Reproduce

Steps to reproduce the behavior:

1. Basic codes added here
2. Compiled for macOS output and test

Basic codes

this.txtOutput = new TextArea();
this.txtOutput.editable = false;
this.txtOutput.layoutData = new VerticalLayoutData(100, 100);
this.addChild(this.txtOutput);
        
var myTimer = new Timer(30000);
myTimer.addEventListener(TimerEvent.TIMER, this.keepAliveTimerHandler, false, 0, false);
myTimer.start();

private function keepAliveTimerHandler(event:TimerEvent):Void
{
        this.txtOutput.text += "["+ Date.now().toString() +"]keepAlive test\n";
}

Expected behavior

Timer should not stop abruptly and keep running.

OpenFL Targets

cpp/macOS

Additional context

Tested on:

• macOS Ventura
• Openfl 9.3.0-Dev
• Lime 8.1.0-Dev

[devsena]

Thank you @joshtynjala for looking into this.

I see a change of behaviour after I updated the NDLL from the recent v8.1.0-Dev build.

Following is the timer-event ticks before system lock (shown in orange) and after unlocking the system (in blue):

Unlike in past, I see timer-event no more fires when the system is locked. Previously, the events were also firing when the system was locked.

Is this change intentional, or how it should be (?)

[devsena]

I see more trouble @joshtynjala . As soon the application minimised (tested on macOS Ventura), timer-event tick stops. This I think is unexpected. openfl.utils.Timer is suppose to run when application minimised, as well.

[Josh Tynjala]

Unlike in past, I see timer-event no more fires when the system is locked. Previously, the events were also firing when the system was locked.
Is this change intentional, or how it should be (?)

Yes, this is intentional (at least on the part of whomever wrote this code before me). Lime was behaving inconsistently when a particular event was dispatched from C++. This change makes Lime's behavior the same whenever this event is dispatched.

It seems to be when a window is hidden on macOS, which (interestingly) also seems to include minimizing the window. I observed that minimizing on Windows did not seem to have the same effect.

This I think is unexpected. openfl.utils.Timer is suppose to run when application minimised, as well.

Unfortunately, this may be tricky. Lime will likely need to dispatch a completely new event in one of these places to support consistency with AIR.

[Josh Tynjala]

openfl/lime@aebf139