Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Closed
MisterMunchkin opened this issue Aug 17, 2021 · 2 comments
Labels

Comments

@MisterMunchkin
Copy link

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
@grbsk
Copy link
Owner

grbsk commented Sep 15, 2021

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.

@grbsk
Copy link
Owner

grbsk commented Nov 21, 2023

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.

@grbsk grbsk closed this as completed Nov 21, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants