useIdleTimer: handler onIdle is not called on long timeout for mobile device if tab is inactive

[AlexHuman]

Bug information

Affected Module

useIdleTimer, workerTimers

• Version: 5.4.0

Describe the bug

Handler onIdle is not called on long timeout (i.e 10 minutes) for mobile device if tab is inactive, even if workerTimers are set as timers.

To Reproduce

Steps to reproduce the behavior:

1. Setup timers, timeout and throttle for useIdleTimer:

useIdleTimer({
    element: document,
    timers: workerTimers,
    timeout: 10 * 60 * 1000, // 10 min
    throttle: 3000, // 3 sec
    onIdle,
    onAction,
  });

2. Open page and make actions
3. Change tab and wait 10min +
4. Return to the first tab

Expected behavior

onIdle is called on time, duration between last action and onIdle call is about 10min.

Actual behavior

onIdle is called only on tab activation.

Screenshots

Time logs:

System Information

• OS: Android 12
• Device: Vivo v21
• Browser Vendor: chrome
• Browser Version: 102
• Other info: USB-debugging with desktop chrome v103
• Timeouts:
  • 4.30 min: OK
  • 5 min: FAIL
  • 10 min: FAIL

• OS: Android 11
• Device: Browserstack Samsung Galaxy s21
• Browser Vendor: chrome
• Browser Version: 100
• Timeouts:
  • 10 min: FAIL

• OS: IOS 15.4
• Device: Browserstack IPhone 11
• Browser Vendor: safari
• Browser Version: 604.1
• Timeouts:
  • 10 min: OK

• OS: IOS 15.4
• Device: Browserstack IPhone 11
• Browser Vendor: chrome
• Browser Version: 92
• Timeouts:
  • 10 min: OK

Additional context

1. Desktop browsers works well thanks to workerTimers.
2. The same issue appears for onPrompt handler and long promptTimeout.

[SupremeTechnopriest]

Thanks for the well reported issue. Gonna have to do some research on this one. The only reason I could think of that this would happen is android chrome is throttling worker execution when the page is backgrounded. To my knowledge, that's not supposed to happen.

I have to find my old android device to debug this. In the mean time can you confirm for me that this only happens with long timers? Could you try setting the timeout to the following intervals and see when it starts being throttled:

• [ ] 1 Minute
• [ ] 3 Minutes
• [ ] 5 Minutes
• [ ] 7 Minutes

Knowing exactly when the throttling starts would help direct my research.

Thanks!

[AlexHuman]

Hi, @SupremeTechnopriest

I checked some timeouts and figured out that execution of workers stops after 5 minutes.

By the way, onIdle call leads to rendering my custom <Timer/> (written with worker-timers). I've set 4.30 minutes for useIdleTimer and 30 seconds for my timer. And after 5 minutes from the last action: onIdle works well, worker of my<Timer/> was blocked.

[AlexHuman]

Checked IOS, OK for 10 min. Updated System Information

[SupremeTechnopriest]

That's very interesting.... I'm afraid there might not be much we can do about this. Might have to open an issue on https://github.com/GoogleChrome/developer.chrome.com. This is actually the first instance where I've seen safari work better than chrome. Haha.

Out of curiosity, what happens if you don't use worker timers?

[AlexHuman]

Out of curiosity, what happens if you don't use worker timers?

Checked for Android chrome for 4.30, 5 and 10 min. The same behaviour as we set worker timers 🧐

[AlexHuman]

Checked IOS chrome 10 minutes, it OK (add to System Information). What a magic!

[SupremeTechnopriest]

Yeah IOS on chrome is actually running webkit. Safari does not support the actual chrome engine blink. So that makes sense. This sounds like a bug in the chrome engine for mobile. I think we are going to have to report it and wait for a fix from them, which is unfortunate... Sounds like the workers stop executing when the app is backgrounded for more than 5 mins.

[ivansky]

Despite of the possible bug, there might be some mobile optimisations that just stops the whole page, timeouts, intervals, etc.

There is an event visibilitychange https://developer.mozilla.org/en-US/docs/Web/API/Document/visibilitychange_event

It could be used to remember the exact time when user leaves a tab and check if a callback was fired otherwise it needs to invoke it on user returns back.

[SupremeTechnopriest]

Can we try this again against the latest release candidate? I think some other changes might resolve this as well. npm i react-idle-timer@next.

[QassemNa]

Not OP, but I tested latest release candidate multiple times in browser and it has always detected idle time, tested on chrome browser and in IOS web view app. and run the same test in the latest release it was almost always failing. So the issue seems to be solved

the times settings were timeout: (1000 * 60 * 9), promptTimeout: (1000 * 60)

[abhijeetrko]

I am facing the above issue with latest release as well. Is there any fix or workaround for solving same? if any Please suggest

[zhangjianrencai]

@AlexHuman how do you define your workerTimers