Question: Does ng-idle still work even after user closed tab/closes browser?

[MisterMunchkin]

Describe the bug I just want to know if this still works if browser closes. The behavior I'm looking for is that if the user closes the browser, and waits for lets say 15 minutes, if the user goes to the app again, it should timeout the user right? since idle is using localstorage.

Expected behavior

• User uses app
• closes tab/browser
• expires the time set in ng-idle
• reopens app
• timeout is true

[moribvndvs]

There are two components in play:

1. Interrupts: Events coming from something, like a window, or an HTMLElement on the document, etc. that should be considered as the user being active when they occur (e.g. when I move the mouse over the document, Idle should consider them active)
2. Expiry: We store the last time the user appears to have been active (a valid interrupt occurred) as a timestamp. I think by default we use localStorage to store the timestamp. When we receive an interrupt event, we get the last timestamp from the expiry. If the difference between now and the timestamp is greater than the idle time, the user is immediately marked as inactive and your application can act as if they timed out. Otherwise, it updates the timestamp and continues as normal.

So generally speaking, based on default configuration, yes it should keep track of the last time they were active before the browser/tab was closed and time them out when an interrupt happens when the app is loaded again. One trick here is kicking off an interrupt once the app is reloaded/reactivated: it may appear active until they do something that causes an interrupt, which kicks off the expiry check mentioned above. By default, this could result in a flash of normal content and then your idle handling kicks in, which could look jarring or confusing. Typically, this is most visible when you hide a tab until it expires, then flip over the tab carefully without triggering your interrupt.

To deal with this, you could experiment with adding a WindowInterruptSource using focus as the event to your current interrupt sources, or change the events used in DocumentInterruptSource (if using; most people are) to include visibilitychange event. The reason these weren't included by default was because of inconsistency.

[moribvndvs]

In addition to the above comments, #131 has made a change that can help with this problem. But be aware, unless you implement your interrupt/expiry, closing a tab/browser and reopening will not restore the idle state where the user left off.