1752594 - [meta] Tabs reload too often in Fenix

Status: NEW

(GeckoView :: General, defect, P2)

Description

[[:owlish] 🦉 PST]

When switching between tabs, the tabs reload much more often than users would expect.

Github issues with more information: https://github.com/mozilla-mobile/fenix/issues/9039 and https://github.com/mozilla-mobile/fenix/issues/12731. The discussions are summarized here https://docs.google.com/document/d/1oAlGdeDHFRm886bPpFt8GxgSoXfeFiBEffc-MxdOePE/edit?usp=sharing

Lines of investigation:

• Possible state management bug in AC where tabs are unloaded
• Possible incorrect prioritization or management of processes by Gecko and/or incorrect relay of those priorities to Android by GV
• Possible high memory consumption by WebRender

Comment 1

[Mark]

You could add https://github.com/mozilla-mobile/fenix/issues/23140#issuecomment-1011494757, Fenix process killed due to "excessive CPU".

I see this several times a day on my Samsung Galaxy M32. Might be a Samsung only issue?

Comment 3

[Chris Peterson [:cpeterson]]

Moving this meta bug out of the sprint. Kaya will file new bugs for his specific areas of investigation.

Comment 4

[Mark]

FWIW on my Galaxy M32 6 GB Android 13, Fenix tabs stay loaded pretty well but if I I go App Info > Battery and change it from Optimised to Restricted it becomes awful, it won't reliably keep 4 tabs loaded. I just wonder if some of the users who are really badly affected have Battery Restricted set, either by user intervention or by OEM design.

I think Battery Restricted is aka "restrict app use in the background", it says notifications might be delayed.

In the Restricted case the task killer becomes incredibly aggressive even if I have lots of free memory as shown in Settings > Developer Options > Running Services > Show cached processes. Open 4 tabs in Fenix; put Fenix in the background; lock phone; wait 30 seconds; unlock phone and usually one or all Fenix processes have been killed.

This is me trying to keep 4 tabs loaded in Fenix with very light/zero use of other apps, when App Info > Battery is Restricted. It's brutal.

12-12 09:47:33.950 1427 1479 I ActivityManager: Killing 6240:org.mozilla.fenix:tab25/u0a275 (adj 930): cached idle & background restricted
12-12 09:47:33.952 1427 1479 I ActivityManager: Killing 3394:org.mozilla.fenix/u0a275 (adj 910): cached idle & background restricted
12-12 09:47:33.954 1427 1479 I ActivityManager: Killing 6469:org.mozilla.fenix:gpu/u0a275 (adj 920): cached idle & background restricted
12-12 09:47:33.955 1427 1479 I ActivityManager: Killing 7253:org.mozilla.fenix:media/u0a275 (adj 935): cached idle & background restricted
12-12 09:47:33.955 1427 1479 I ActivityManager: Killing 6675:org.mozilla.fenix:tab7/u0a275 (adj 950): cached idle & background restricted
...
12-12 10:06:59.921 1427 1479 I ActivityManager: Killing 11152:org.mozilla.fenix:gpu/u0a275 (adj 900): cached idle & background restricted
12-12 10:06:59.924 1427 1479 I ActivityManager: Killing 12120:org.mozilla.fenix:media/u0a275 (adj 935): cached idle & background restricted
12-12 10:06:59.924 1427 1479 I ActivityManager: Killing 12653:org.mozilla.fenix:utility/u0a275 (adj 920): cached idle & background restricted
12-12 10:06:59.925 1427 1479 I ActivityManager: Killing 11100:org.mozilla.fenix:tab32/u0a275 (adj 960): cached idle & background restricted
...
12-12 10:09:29.575 1427 1479 I ActivityManager: Killing 12901:org.mozilla.fenix:gpu/u0a275 (adj 930): cached idle & background restricted
12-12 10:09:29.579 1427 1479 I ActivityManager: Killing 13013:org.mozilla.fenix:tab16/u0a275 (adj 900): cached idle & background restricted
...
12-12 10:15:01.679 1427 1479 I ActivityManager: Killing 13498:org.mozilla.fenix:gpu/u0a275 (adj 900): cached idle & background restricted
12-12 10:15:01.683 1427 1479 I ActivityManager: Killing 11569:org.mozilla.fenix:tab15/u0a275 (adj 920): cached idle & background restricted
...
12-12 10:59:30.056 1427 1479 I ActivityManager: Killing 20180:org.mozilla.fenix:gpu/u0a275 (adj 900): cached idle & background restricted

This does not happen if App Info > Battery is set to Optimised

Cheers & hope it's helpful

Comment 5

[Mark]

Opened https://github.com/mozilla-mobile/fenix/issues/28452 which is a re-opening of https://github.com/mozilla-mobile/fenix/issues/23140 (closed by stalebot).
It's still a problem for me on a couple of Samsung devices.

Comment 6

[mohibo2085]

(In reply to Mark from comment #4)

FWIW on my Galaxy M32 6 GB Android 13, Fenix tabs stay loaded pretty well but if I I go App Info > Battery and change it from Optimised to Restricted it becomes awful, it won't reliably keep 4 tabs loaded. I just wonder if some of the users who are really badly affected have Battery Restricted set, either by user intervention or by OEM design.

I think Battery Restricted is aka "restrict app use in the background", it says notifications might be delayed.

In the Restricted case the task killer becomes incredibly aggressive even if I have lots of free memory as shown in Settings > Developer Options > Running Services > Show cached processes. Open 4 tabs in Fenix; put Fenix in the background; lock phone; wait 30 seconds; unlock phone and usually one or all Fenix processes have been killed.

This is me trying to keep 4 tabs loaded in Fenix with very light/zero use of other apps, when App Info > Battery is Restricted. It's brutal.

12-12 09:47:33.950 1427 1479 I ActivityManager: Killing 6240:org.mozilla.fenix:tab25/u0a275 (adj 930): cached idle & background restricted
12-12 09:47:33.952 1427 1479 I ActivityManager: Killing 3394:org.mozilla.fenix/u0a275 (adj 910): cached idle & background restricted
12-12 09:47:33.954 1427 1479 I ActivityManager: Killing 6469:org.mozilla.fenix:gpu/u0a275 (adj 920): cached idle & background restricted
12-12 09:47:33.955 1427 1479 I ActivityManager: Killing 7253:org.mozilla.fenix:media/u0a275 (adj 935): cached idle & background restricted
12-12 09:47:33.955 1427 1479 I ActivityManager: Killing 6675:org.mozilla.fenix:tab7/u0a275 (adj 950): cached idle & background restricted
...
12-12 10:06:59.921 1427 1479 I ActivityManager: Killing 11152:org.mozilla.fenix:gpu/u0a275 (adj 900): cached idle & background restricted
12-12 10:06:59.924 1427 1479 I ActivityManager: Killing 12120:org.mozilla.fenix:media/u0a275 (adj 935): cached idle & background restricted
12-12 10:06:59.924 1427 1479 I ActivityManager: Killing 12653:org.mozilla.fenix:utility/u0a275 (adj 920): cached idle & background restricted
12-12 10:06:59.925 1427 1479 I ActivityManager: Killing 11100:org.mozilla.fenix:tab32/u0a275 (adj 960): cached idle & background restricted
...
12-12 10:09:29.575 1427 1479 I ActivityManager: Killing 12901:org.mozilla.fenix:gpu/u0a275 (adj 930): cached idle & background restricted
12-12 10:09:29.579 1427 1479 I ActivityManager: Killing 13013:org.mozilla.fenix:tab16/u0a275 (adj 900): cached idle & background restricted
...
12-12 10:15:01.679 1427 1479 I ActivityManager: Killing 13498:org.mozilla.fenix:gpu/u0a275 (adj 900): cached idle & background restricted
12-12 10:15:01.683 1427 1479 I ActivityManager: Killing 11569:org.mozilla.fenix:tab15/u0a275 (adj 920): cached idle & background restricted
...
12-12 10:59:30.056 1427 1479 I ActivityManager: Killing 20180:org.mozilla.fenix:gpu/u0a275 (adj 900): cached idle & background restricted

This does not happen if App Info > Battery is set to Optimised

Cheers & hope it's helpful

Tried that, it didn't make any difference

Comment 7

[mohibo2085]

Make your mind, does or doesn't depend on 1810550?

Comment 8

[mohibo2085]

Make your damn mind does it depends on damn 1810550 or doesn't depend on damn 1810550?

Comment 9

[mohibo2085]

I guess advocacy is not in your dictionary :)

Comment 10

[Olivia Hall [:olivia]]

Bug 1847566 is to investigate the browser primary attribute being set in GeckoView during setFocused calls. Not sure if there is any relevance to tab reloading, but it does seem like it has the potential for visible tabs to be de-prioritized if they are not marked primary and should be.

Comment 12

[Mark]

tl;dr

Just to say I am not affected by this bug. For me, Firefox 120 and Nightly 122 are bullet proof. My phones are nothing special, 4 GB Galaxy A40 and 6 GB Galaxy M32. But I can keep eg 8 tabs open for days, swap to several other apps, come back, I never, ever see tab reloads.

Of course I can force tabs to reload if I open lots and lots of other apps, but I have to open an unrealistic number, eight or ten. Just using Firefox, swapping to Aqua Mail then Signal then Acrobat then Gallery and back to Firefox never ever causes a reload of the frontmost tab.

I'm aware of three Android mechanisms which could force a reload when Firefox comes back to the foreground. Firefox 120 is pretty well behaved with respect to all of them, and none of them should really be an issue on a fast phone with 8 GB like an S21. Hmmmm. Perhaps there's a fourth mechanism, or perhaps there's a bug in Firefox which only hits some users/phones.

I might do some more diagnosis, I've got quite good at digging around in log messages and have found a couple of issues which Mozilla has now fixed. But I need a problematic phone and/or reliable steps to reproduce, which I don't currently have.

(I don't work for Mozilla so please don't shout at me, I am just Some Guy on the Internet).

Are there any patterns?

• what devices are you using? (I'm on mid range Samsungs)
• how many tabs do you have open? (me, typically 4-8)
• when you swap to another app then back to Firefox and get a reload, how long have you been away from Firefox? Seconds or minutes?
• when you get a reload issue, which tabs reload:- all / exactly half / just the frontmost one / Firefox has been completely killed and relaunches?
• are any sites particularly badly affected, some form fill ins seem particularly bad?
• any funny add ons? (me, just uBO with a lot of filters and Google Search Fixer)

IIRC users were having problems on Galaxy S8; now I hear a problem on an S21. Does this only occur on Samsung flagships? Does it only occur on particular websites? Does anyone want to buy me an S21?

I even blew the dust of my Sony Xperia with Android 8 and 2.5 GB of RAM and Firefox 120 behaved pretty well, comparable to Edge. As long as I didn't go crazy it kept tabs loaded pretty well.

Background stuff

I'm aware of three mechanisms that could cause tab reloading. Perhaps there's a fourth of which I am not aware. (PS I am no expert in this stuff)

1. voluntary RAM release through onTrimMemory. As memory pressure increases, Android requests the apps which are nearing the top of the Least Recently Used list to reduce their RAM. Firefox 120 is pretty well behaved about how it releases RAM, it unloads tabs gently in a way which keeps the front tab alive longest. But anyway this shouldn't be an issue on an 8 GB phone, Firefox should never get near the top of the LRU list unless the user goes crazy eg backgrounds Firefox and opens a dozen apps.

2. forced kill by lmkd. If the memory pressure is still too great, Android's low memory killer daemon starts to kill processes near the top of the LRU list. Firefox 120 has a main process and two content processes, so an lmkd kill unloads exactly half your tabs; all your tabs; or kills the whole browser. Again lmkd should never get anywhere near Firefox, it shouldn't be anywhere near the top of the LRU list. Recent Samsung devices have their own ChimeraAggressivePolicyHandler which seems to replace lmkd but it does roughly the same thing.

3. forced kill due to excessive CPU. More recent versions of Android are very strict on background CPU use. Android will kill a background app if it eg uses more than 2% CPU in a five minute interval. Firefox is not yet perfect in this regard, I have seen "excessive CPU" kills but (a) Firefox has to be in the background a long time (minutes); (b) the kills are in my experience extremely rare, perhaps once a day; and (c) with a high performance CPU like in an S21, Firefox shouldn't hit that excessive CPU kill threshold very often. There's a fix coming for excessive CPU kills but it's quite some way away.

So, are your tabs being unloaded by one of these Android mechanisms; by an unrelated bug in Firefox; or by a fourth kill Android mechanism? Hmmmm.

Comment 13

[zesanup]

Do you use Private Browsing mode exclusively, Mark? If not, try to see if it gets you the bug.

For me, merely locking the device after leaving a page open can be enough to trigger a refresh upon unlocking. And this forces me to reload the entire app anyway, since the automatic page refresh doesn't restart crashed/closed extensions yet (which will probably be fixed by MV3). This is on a 3 GB device, with around 1.5 used just by the OS. However, even with everything running, I'm shown around 1GB free, which is why this behaviour seems like a Fenix bug and not simply Android freeing up RAM.

Comment 15

[Mark]

@zesanup, Private Browsing is just fine on my Xperia X Compact with 2.5 GB. I tried with and without add-ons, all fine. No reloads unless I go crazy with other apps. Definitely no reloads on unlocking the phone. I tried pretty hard over a day.

If I keep 4-6 tabs open in Firefox I never see reloads for "light use", messaging, mail etc. If I've used several other apps, when I bring Firefox back to the foreground the whole browser repaints (tab bar plus content) REALLY slowly, taking perhaps 1 second. But it's always a repaint, not a reload.
If I open some big apps, eg the Camera app and then Photos, Firefox sometimes gets killed completely and relaunches from the splash screen, and the pages reload. But that seems reasonable.

I was able to put 4 tabs in Firefox and 4 tabs in Edge and run them head to head and they both behaved as expected, if I start opening other apps, the Least Recently Used of Firefox/Edge gets killed and relaunches with a splash screen.

Right now I can't really see any real difference between Firefox and Edge in terms of page load speed or memory pressure handling. That wasn't the case a year or two ago when IME Firefox was terrible compared to Chrom(ium).

Comment 16

[Mark]

(Another long post, sorry)

Santa brought me an S21 FE 6 GB and it has less free RAM than my M32 6 GB :( I think the Android system uses so much more RAM because of all the Samsung bloatware. The S21 FE definitely reloads tabs more often than the M32, especially if I open the Camera app. But the reload occurs on both Samsung Internet (Chromium) and Fenix Nightly.

I think it's Issue 2 from bug 1752594 comment 12, even on a phone with plenty of RAM, memory is in short supply and lmkd is quite aggressive. And the foreground tab in current builds of Fenix is more vulnerable to lmkd than Chromium because Fenix has only two large tab processes each containing many tabs whereas Chromium has one process per tab. If lmkd gets aggressive with Fenix it can kill both tab processes, which causes the foreground tab to reload. If lmkd gets aggressive with Chromium it is more granular, it kills tabs one by one starting with the least-recently-used, and usually lmkd is satisfied that enough RAM has been released before it gets to the foreground tab.

Fenix also has a GPU process (fenix:gpu) and an add-ons process which I think is listed like a tab process (fenix:tabxx).

Example log below of me running Samsung Internet and Fenix Nightly head to head, then opening a few apps ending up with the Camera app. Samsung Internet has two tabs killed, but not the foreground tab. Fenix has both tab processes, the gpu process and the add-ons process killed, so every tab reloads including the foreground one.

But I think this problem is substantially fixed by enabling Fission on Fenix (I expect devs would not recommend this yet). Fission gives one process per tab and I think behaves much more like Chromium, lmkd can be more granular in its tab killing. I'm not 100% sure on this, still testing.

@devs, I worry about the add-ons process, which IIUC doesn't exist in Chromium. I think the add-ons process often falls to the point in the Least Recently Used list where it is very vulnerable to an lmkd kill, and IIUC if the add-ons process gets killed, every tab in Fenix reloads. So Fenix might have a kind of dead man's handle process which isn't present in Chromium, if lmkd kills the dead man's handle process all the tabs die including the foreground tab. I think I have seen this happen but don't have a log. (Perhaps I misunderstand how this all works).

12-30 15:49:00.524   731   731 I lmkd    : Reclaim 'com.samsung.android.scs' (23149), uid 10101, oom_score_adj 945, state 19 to free 80620kB rss, 32752kB swap; reason: low watermark is breached and swap is low (2310952kB < 419428kB)
12-30 15:49:00.579   731   731 I lmkd    : Reclaim 'com.google.android.gms' (23466), uid 10238, oom_score_adj 935, state 19 to free 132912kB rss, 32904kB swap; reason: low watermark is breached and swap is low (2310952kB < 419428kB)
12-30 15:49:00.626   731   731 I lmkd    : Reclaim 'com.sec.android.app.sbrowser.beta:sandboxed_process0:org.chromium.content.app.SandboxedProcessServ' (21971), uid 99058, oom_score_adj 980, state 98 to free 119884kB rss, 45140kB swap; reason: low watermark is breached and swap is low (2311464kB < 419428kB)
12-30 15:49:00.689   731   731 I lmkd    : Reclaim 'com.sec.android.app.sbrowser.beta:sandboxed_process0:org.chromium.content.app.SandboxedProcessServ' (24014), uid 99060, oom_score_adj 970, state 98 to free 163888kB rss, 37660kB swap; reason: low watermark is breached and swap is low (2319400kB < 419428kB)
12-30 15:49:00.743   731   731 I lmkd    : Reclaim 'org.mozilla.fenix:tab39' (23760), uid 10342, oom_score_adj 940, state 17 to free 246644kB rss, 35240kB swap; reason: low watermark is breached and swap is low (2319656kB < 419428kB)
12-30 15:49:01.253   731   731 I lmkd    : Reclaim 'org.mozilla.fenix:tab11' (17635), uid 10342, oom_score_adj 930, state 17 to free 190160kB rss, 128872kB swap; reason: low watermark is breached and swap is low (2320680kB < 419428kB)
12-30 15:49:01.415   731   731 I lmkd    : Reclaim 'org.mozilla.fenix:tab29' (5234), uid 10342, oom_score_adj 920, state 17 to free 95684kB rss, 141216kB swap; reason: low watermark is breached and swap is low (2437160kB < 419428kB)
12-30 15:49:01.462   731   731 I lmkd    : Reclaim 'org.mozilla.fenix:gpu' (23650), uid 10342, oom_score_adj 910, state 17 to free 174704kB rss, 33460kB swap; reason: low watermark is breached and swap is low (2512000kB < 419428kB)

Comment 17

[TexlGyTrail]

Not sure how helpful this will be for the developers, but on my Galaxy S8+ with 4 GB of RAM (Android 9), I could vastly improve Firefox's tab “longevity” in the background by having some sort of media playback running or at least by having Firefox “detect” some sort of playback.

For example, I used this site's sine wave player (audiocheck.net) to test this. You don't have to keep playing the 1000Hz sine wave audio, just press play once and then pause it, and the trick should still work. Having Firefox detect media playback in the background helped me keep a very reload-happy site from getting killed as soon as I left the app. It's not 100% perfect, tabs can still get killed if I push multitasking too hard on my 4 GB phone, but keep in mind I'm running my Firefox with a ton of add-ons.

The catch is that the media playback needs to be running from the same “shared” web process as the website/tab you want to keep in the background forcefully. Using about:processes will help you verify if both the “audiocheck.net” (or whatever site you might use to test this) website and the websites of your tabs are “Subframes” under one “Shared Web Process”. You might have to fiddle around with opening and closing tabs until you can get them both on the same process. I'd assume this would be harder to achieve or maybe impossible if you have Fission enabled on Android.

I don't know how much or if this might affect battery life, though if I had to guess it's probably not going to improve it. If someone more knowledgeable can think of a faster or easier way of replicating this workaround, feel free to let everyone know.

Comment 18

[premavansmuuf+git]

Since this buggy behavior of Firefox for Android effectively prevents me from paying online with credit card:

1. Fill in a credit card info and submit the payment within Firefox.
2. My bank's authorization app requires me to switch to it, so I can confirm the payment (3D Secure), so I do it.
3. Then I return to Firefox... and the whole page is refreshed; the payment progress is discarded.
4. Loss - I cannot pay online while using Firefox.

... I'd like to dispute the specified S3 severity of this bug. Aggressive tab reloading leading to losing an online payment transaction seems like a "severely impaired product with no satisfactory workaround" (unless you count switching to Chrome as satisfactory workaround), so according to https://wiki.mozilla.org/BMO/UserGuide/BugFields#bug_severity that would be at least S2 severity.

IMHO someone needs to give this thing a much bigger priority. It's a problem I encounter every single day several times and I'm sure I'm not the only one, yet it remains unresolved for almost 2 years now. (And as far as I can see it's not even in any way apparent if its being actively worked on.)