Bug #1205
closedwebpage re-downloaded every time focus shifts
0%
Description
A broken captive portal was rendered saying to tick an “I accept” box, but it did not actually render the tickbox. That’s probably a bug with the captive portal server not the browser. But it was important that I capture the broken page, so I left the browser screen untouched but used other apps throughout the rest of the day, so that upon returning home I could attach adb and capture the screen. When the still-loaded Privacy Browser instance is brought back into focus, it shows a number of initialization activities as if the app is being launched. The loaded webpages are refreshed. Obviously I’m no longer connected to the captive portal that produces the agreement page, so it cannot be reloaded because I’m no longer on that network and access is denied. Effectively, there is no way to capture a window when it renders differently on different networks.
Regardless of the particulars of the captive portal situation, it’s a bad behavior to needlessly re-fetch already loaded webpages. Especially on a phone because data plans are not unlimited. It’s very wasteful with data credit even in more normal circumstances where refreshing a static page doesn’t break the original render.
This bug seems similar:
https://redmine.stoutner.com/issues/139
My experience is on version 3.8.1, so I’m not sure if the fix for bug 139 would be in my version.
Updated by Soren Stoutner 11 days ago
- Status changed from New to Closed
3.8.1 is very old. I would recommend you update to the current 3.18 (and to a modern version of Android that supports versions of Privacy Browser newer than 3.8.1).
But regardless of the version you are running, what you are describing is simply the Android Activity Lifecycle. Basically, Android closes apps that are in the background. There is nothing an app can do to prevent this. When the app is relaunched, it has to reload all its data.
You can read more about this at:
https://developer.android.com/guide/components/activities/activity-lifecycle
Updated by john doe 10 days ago
I hope this edit button does not actually wipe out my bug report. I don’t see a button to add a comment.
Thanks for the explanation. I’ve noticed that my music player and VOIP apps continue in the background without activity interruption, so there must be a more reasonable approach the browser can take. If not, surely the browser could save its state as part of the graceful kill handler, then recover the saved state regardless of the network.
Regarding the version, I am trapped on AOS 5 and Androids are designed for forced obsolescence. I’ll have a look at whether I can find a later browser version but I would have expected f-droid to offer one by now if there is one in the repo.
Updated by Soren Stoutner 10 days ago
I have written about this extensively, so instead of explaining it again I will simply post a few links. In addition to the link in my previous comment about Android Activity Lifecycles (which I would recommend you read in full), I would also recommend:
https://www.stoutner.com/saved-instance-state/
https://www.stoutner.com/if-you-have-too-many-tabs-sometimes-they-disappear/
Each of these pages have links to other resources that explain various aspects of this topic.