1810514 - setInterval() and setTimeout() timers not running if the Geckoview is backgrounded on Android

Status: UNCONFIRMED

(GeckoView :: General, defect, P2)

Description

[jw]

Steps to reproduce:

We use Geckoview in our line-of-business app, with the intention that even when backgrounded the business logic inside the Geckoview continues to run (and we follow's Android best practice by using a foreground service to inform the user of this etc, with the caveat that Android may evict our app if low on resources).

We see that if you return to the home screen on Android while the app is running and lock the device, then, after a period of time, timers stop firing (i.e. we go through an onPause()/onStop() steps of the activity lifecycle).

In this state, we can connect a remote debugger and inspect the state of the Geckoview, but anything queued using setInternal() or setTimeout() doesn't fire. Any previously created timers don't fire either.

Is this by design? Is there any way to make the Geckoview continue to fire timers when in the background?

When you bring the Geckoview back into the foreground, all pending or queued timers all fire immediately.

Actual results:

When in this state, even timers created using the Debugger don't fire.

For example, using the Console tab of the Debugger you can run:
setTimeout(() => console.error ("hello"), 5000);
but "hello" is never written to the console.

Expected results:

Timers to continue to run when the Geckoview is in the background.

Comment 1

[BugBot [:suhaib / :marco/ :calixte]]

The severity field is not set for this bug.
:cpeterson, could you have a look please?

For more information, please visit auto_nag documentation.

Comment 2

[Chris Peterson [:cpeterson]]

Irene, is this behavior by design? Does GeckoView pause all web content timers like setInternal() and setTimeout()? I know we pause some timers for background tabs or when the Firefox app is backgrounded. I don't know how much of that logic is in GeckoView versus the Firefox app's front-end code.

Comment 3

[[:owlish] 🦉 PST]

I'll check but I don't think GeckoView has any logic for that at all, I think this is what comes from Gecko

Comment 4

[Ragnarok]

Will this ever get fixed ?
https://bugzilla.mozilla.org/show_bug.cgi?id=1848178

Comment 5

[Ragnarok]

Even a extension that blocks all way a page detect if user has minimized the bowser.. the countdown is still paused
https://addons.mozilla.org/en-US/firefox/addon/always-visible/?utm_source=addons.mozilla.org&utm_medium=referral&utm_content=collection

Comment 6

[Ragnarok]

This is annoying as hell and shouldn't take this long to address.. specially if someone's regularly going through link shortners

Comment 8

[Ragnarok]

I have fixed this using a Userscript by Hijacking setTimeout/setInterval to run in a Web Worker, bypassing background tab throttling.
I tested on bunch of sites and in 1 site in didnt work( i have patched all things that can pause timer)

If not fixing this is a battery concern for general people add the option to ignore background throttling in secret settings people like me dont care about battery but care about time😭

How many more years for this😾😿

Comment 9

[Ragnarok]

I'll consider this fixed by
Going to about:config
dom.suspend_inactive.enabled > False
dom.workers.throttling.enabled > False

Fixed for me

Also the UserScript worker fix is also perfectly working for all sites too🌚