Skip to content

setInterval callback is not fired while touch events are being processed #2116

Closed

Description

@the-reality-engineer

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. 

Activity

  1. self-assigned this
    on May 16, 2016
  2. tsonevn commented on May 16, 2016

    @tsonevn
    Contributor

    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

  3. the-reality-engineer commented on May 17, 2016

    @the-reality-engineer
    ContributorAuthor

    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.

  4. removed their assignment
    on Nov 1, 2016
  5. added this to the milestone on Dec 5, 2016
  6. modified the milestones: 2.5.0, on Dec 5, 2016
  7. hshristov commented on Dec 5, 2016

    @hshristov
    Contributor

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

  8. jasssonpet commented on Dec 6, 2016

    @jasssonpet
    Contributor

    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.

  9. self-assigned this
    on Dec 13, 2016
  10. hamorphis commented on Dec 13, 2016

    @hamorphis
    Contributor

    @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.

  11. jasssonpet commented on Dec 13, 2016

    @jasssonpet
    Contributor

    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.

  12. hamorphis commented on Dec 13, 2016

    @hamorphis
    Contributor

    @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.

  13. jasssonpet commented on Dec 13, 2016

    @jasssonpet
    Contributor

    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.

  14. hamorphis commented on Dec 13, 2016

    @hamorphis
    Contributor

    Isn't the sleep freezing it?

  15. hamorphis commented on Dec 13, 2016

    @hamorphis
    Contributor

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

  16. added a commit that references this issue on Dec 13, 2016
    5338484
  17. added a commit that references this issue on Jan 3, 2017
    9d2a98f
  18. lock commented on Aug 29, 2019

    @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.

  19. locked and limited conversation to collaborators on Aug 29, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Type

No type

Projects

No projects

    Milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions