Unclear which events trigger "activity" for idleTimer

[donp-usbank]

We have implemented idleTimer in a production application, and our testing is showing inconsistent behavior with when the timer is reset, or when it expires/prompts.

1. In some cases, we see behavior that seems to suggest that the activity switching from the application tab to a different tab, and then back to the application tab - without any actual activity in the browser DOM (mouse events, keyboard events, etc) - are causing the timer to reset. So if the timer is 15 minutes, and we switch tabs from the application to toher tabs over the course of 5 minutes, then the timer expires in 20 minutes, not 15 minutes.

2. In other cases, specifically on a Mac with Safari v17.3, we're seeing that staying in the application tab with no activity whatsoever, the timer will never expire and will never prompt. So with a timer of 15 minutes, even after 15 minutes we see no prompt.

I see in the docs for the events prop it says "DOM events to watch for activity on". So our question is:

• Is the implementation expected to trigger reset only for events in the application's tab?
• Will the implementation also have its timer reset for the activity of switching tabs?

I.e., is the scope of events that will cause timer reset the application tab/window, the entire browser window, or all computer input device events?
And how does this explain the second case above?

Thank you.

[SupremeTechnopriest]

The visibilitychange event is part of the default events. See here. So changing focus of the tab is going to reset the timer. If you want to omit that event you can pass your own array of events to the events property.

const idletimer = useIdleTimer({
  events: [
    'mousemove',
    'keydown',
    'wheel',
    'DOMMouseScroll',
    'mousewheel',
    'mousedown',
    'touchstart',
    'touchmove'
  ]
})

[donp-usbank]

Thanks for that @SupremeTechnopriest

Along those same lines - do you know if that would have the effect of restricting the timer to events only within the DOM of the application tab?

In other words - if we only want the timer to be affect by events specifically within our application's browser tab, would this do it? Or is there a way to achieve that?

Thanks

[SupremeTechnopriest]

Yes it will.

[donp-usbank]

Thank you!

[donp-usbank]

Thanks again @SupremeTechnopriest - one follow-up question:

Your suggestion above for restricting the timer reset events to the browser tab/window that's hosting the timer was to use this set:

const idletimer = useIdleTimer({
  events: [
    'mousemove',
    'keydown',
    'wheel',
    'DOMMouseScroll',
    'mousewheel',
    'mousedown',
    'touchstart',
    'touchmove'
  ]
})

The default array of events is:

[
  'mousemove',
  'keydown',
  'wheel',
  'DOMMouseScroll',
  'mousewheel',
  'mousedown',
  'touchstart',
  'touchmove',
  'MSPointerDown',
  'MSPointerMove',
  'visibilitychange'
]

So in your suggestion, in addition to removing visibilityChange, these are also removed: 'MSPointerDown', 'MSPointerMove'.

When I look at what those events mean, I see:

The pointerdown event is fired when a pointer becomes active. For mouse, it is fired when the device transitions from no buttons pressed to at least one button pressed. For touch, it is fired when physical contact is made with the digitizer. For pen, it is fired when the stylus makes physical contact with the digitizer.

It's hard to tell if this would be fired only in the context of the attached tab's DOM or not. Do you know what this event does in the context of idleTimer - if visibilityChange is removed would MSPointerDown still be emitted on a tab other than the tab where idleTimer is running?

Thanks

[SupremeTechnopriest]

You can keep the MS events if you want to support older IE browsers. Just removing visibilitychange will be enough to achieve what you are after.