You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
setInterval callback is not fired while touch events are being processed #2116
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.
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.
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.
@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.
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.
@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.
Activity
tsonevn commentedon May 16, 2016
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
setIntervalcallback is to press some of theListViewitems and then to pressButton. I am attaching my sample project.https://github.com/tsonevn/setIntervalNativeScript.git
Regards,
@tsonevn
the-reality-engineer commentedon May 17, 2016
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 commentedon Dec 5, 2016
@jasssonpet Could you please check if UI is getting higher priority than setInterval?
If so can we fix it somehow?
jasssonpet commentedon Dec 6, 2016
This looks familiar to this issue here: https://stackoverflow.com/questions/9090658/
The created timer should be added to the
NSRunLoopCommonModesmode if it should have such high priority.hamorphis commentedon Dec 13, 2016
@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 commentedon Dec 13, 2016
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 commentedon Dec 13, 2016
@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 commentedon Dec 13, 2016
I am testing with the following snippet:
and the UI can freeze for 2 seconds while scrolling which is unpleasant.
hamorphis commentedon Dec 13, 2016
Isn't the sleep freezing it?
hamorphis commentedon Dec 13, 2016
Anyway, we have decided to add it to our code by default.
Fix: setInterval callback is not fired while touch events are being p…
Fix: setInterval callback is not fired while touch events are being p…
lock commentedon Aug 29, 2019
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.