setInterval callback is not fired while touch events are being processed

[speigg]

Did you verify this is a real problem

Yes

Tell us about the problem

setInterval callbacks are essentially paused during a touch interaction. This includes touches that happen via a scrollview, or gestures (like a pan gensture).

Which platform(s) does your issue occur on?

iOS

Please provide the following version numbers that your issue occurs with:

• CLI: 1.7.0
• Cross-platform modules: 1.7.1
• Runtime(s): 1.7.0
• Plugin(s): n/a

Please tell us how to recreate the issue in as much detail as possible.

Create a callback that fires with setInterval, say, every 20 milliseconds (frequently enough for doing a dynamic animation, like with physicsjs). Create a scrollview or add a gesture recognizer to a view, and note that when the app is processing touch events, the setInterval callback does not fire. Once the touch interaction is done processing, the setInterval callback resumes.

Is there code involved? If so, please share the minimal amount of code needed to recreate the problem.

setInterval(()=>console.log(Date.now()));
// scrollview or something that handles touches. 

[tsonevn]

Hi @speigg,
Thank you for reporting this issue.

I tested your scenario and confirm this is real issue for iOS. I found that the only way to fire setInterval callback is to press some of the ListView items and then to press Button. I am attaching my sample project.

https://github.com/tsonevn/setIntervalNativeScript.git

Regards,
@tsonevn

[speigg]

Your test case seems a bit more complicated than necessary since you are calling setInterval in response to touch events. If you simply call setInterval(()=>console.log(Date.now()), 20) once when the app starts, then try scrolling a view, you should see that the interval is paused while scrolling happens.

[hshristov]

@jasssonpet Could you please check if UI is getting higher priority than setInterval?
If so can we fix it somehow?

[jasssonpet]

This looks familiar to this issue here: https://stackoverflow.com/questions/9090658/

The created timer should be added to the NSRunLoopCommonModes mode if it should have such high priority.

[hamorphis]

@jasssonpet I can add the timer to the NSRunLoopCommonModes by default after it is created in our code. Do you see any potential danger (i.e. UI performance) in doing this or should present a public API for the developer to do this only if he considers it safe and let him be the one responsible for this decision.

[jasssonpet]

My thinking is that there could be UI performance issues depending on the frequency and complexity of the user callbacks. I believe that's why Apple chose to make it an opt-in for a higher priority and in my opinion we should follow this way.

[hamorphis]

@jasssonpet Interesting. I added the timer to the current loop with the common modes and initially it was very responsive while scrolling. But after some scrolling it stopped printing again. Not much we can do I guess. Maybe console logging each 20 ms is insane anyway.

[jasssonpet]

I am testing with the following snippet:

setInterval(function() {
    console.log(new Date() / 1000);
    sleep(2); // Simulating some potentially heavy work
}, 1000);

<ScrollView>
    <StackLayout>
        <Label text="Label 1" />
        <!-- ... -->
        <Label text="Label 99" />
    </StackLayout>
</ScrollView>

and the UI can freeze for 2 seconds while scrolling which is unpleasant.

[hamorphis]

Isn't the sleep freezing it?

[hamorphis]

Anyway, we have decided to add it to our code by default.

[lock]

This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.