How to prevent idle timeout using same sibgle browser with multiple tabs?

[RamuDhanush]

I'm submitting a ... (check one with "x")

[ ] bug report => search github for a similar issue or PR before submitting
[ ] feature request
[ ] support request => Please do not submit support request here, instead see https://github.com/HackedByChinese/ng2-idle/blob/master/CONTRIBUTING.md#getting-help

Current behavior Once logged in my application I enabled idle.watch() then click one of the link, it should opened another tab in same browser with same domain. I was active in newly opened tab. But once reached I mentioned timeout seconds then my main tab window was got session timeout warning message.

Expected behavior Main tab window should be active.

Minimal reproduction of the problem with instructions Package.json: "@ng-idle/core": "2.0.0-beta.12",

In TS: import { Idle, DEFAULT_INTERRUPTSOURCES } from '@ng-idle/core';

idle.setInterrupts(DEFAULT_INTERRUPTSOURCES); this.idle.setIdle(2 * 60); this.idle.setTimeout(60); // 1 minute this.idle.watch();

My main window URL: http://localhost:3000/users/dashboard

Once click the link in main window: var openPopUpWindowHandle = window.open("http://localhost:3000/find/faq", "windowname");

What is the motivation / use case for changing the behavior? Need to active on child tab as well

Please tell us about your environment: Running on windows OS

• @ng-idle version: @ng-idle/core": "2.0.0-beta.12"

• Angular version: @angular/core": "~2.4.0"

• Browser: Latest version on Chrome, Edge, Firefox and IE 10 and 11

• Language: "typescript": "~2.0.10",

• Node: v8.16.0

[Naveed1842]

Is there any update on this?

[moribvndvs]

It’s possible the inactive tab suspended JS timers. No timers firing = no idle state. If you trigger activity in the suspended tab after your expiry, does it seem to fire off the timed out event?

when an interrupt occurs, the first thing we do is check if the last active time has exceeded the timeout. That is a signal to us that the process has been inactive during the time it normally would have timed out, and so rather than interrupt normally we jump right to timed out. Since by default we publish last activity to session storage, all your tabs should be checking this and abiding this expectation.

Often people set up this experiment, let one window time out and look at the other expecting it to be in lockstep, see that it isn’t, and walk away with “it doesn’t work”. If they clicked or something, it should trigger their timeout action, indicating it’s working as expected. If that’s not the case for you, well, ok, something is up.

All things working as expected aside, I do realize people typically expect that lockstep experience. As I said, however, browser JS engines have a say on that as I mentioned above. To try and work around this, there is an interrupt source called ‘WindowInterruptSource’ to listen to active/focus, or use ‘DocumentInterruptSource’ with [this event| https://developer.mozilla.org/en-US/docs/Web/API/Document/hidden#browser_compatibility], or implement your own interrupt source. Why is this not supported out of the box with defaults? Well, people complained it created problems, worked inconsistently between browsers or in general, so I had to leave it to the implementer.

I’m open to better ideas if someone has a rock solid, cross browser and platform solution.

FWIW, the demo app works as expected when I dupe the tab and let it expire in one then perform an action in another.