Privacy Browser Android

By the way, you can get a Logcat from the Navigation menu inside Privacy Browser.

Damn demonstration effect :-)
No, not allways, last 5 openings ran smoothly.
Will come back after next occurance(s) with new logcat.

OK?

That logcat is sufficient as it shows the crash clearly. I just needed to know if this always happened, as that indicates what the underlying cause is. In this case, with it being intermittent, the most likely cause is a race condition between the creation of the tab and the WebView that leaves the system out of sync, but I am not yet certain where that is occurring.

Same issue as of #1134, but different description. Although still can't reproduce this consistently. It's still random.
And no. Closing the new tab doesn't crash PB for me. It just exhibits the bug. That's it.

You won't be able to reproduce it consistently. It is what is called a race condition, which means that two things are happening simultaneously in the background (a race). If one finishes first, everything is fine. If the other finishes first, there is a crash.

Race conditions are very tricky because sometimes they only manifest on certain hardware or on certain versions of Android or under other conditions that make them hard to replicate. Among other things, that can make it hard to know when you have fixed them.

Maybe the implementation of opening new tabs as adjacent (#1100), is still incomplete & requires proper lookup ?

A quick search on avoiding race conditions, says that the critical section of a resource sharing has to be atomical, as well as proper thread synchronisation.

That's possible, although it could also be that the bug has existed for a while and nobody noticed or that it was introduced by some other recent change different from the opening of tabs adjacently.

Most likely it relates to all the problems in switching from ViewPager to ViewPager2 in Privacy Browser 3.14 with Feature #587: Switch FragmentPagerAdapters to FragmentStateAdapters. ViewPager2 is much more asynchronous than the previous implementation, which has ended up introducing dozens of bugs into the project (most of which I fixed in my testing before they were ever released to the public). As almost all of them are race conditions (which is what you get when you make things asynchronous), finding and squashing them all has been rather difficult. For example, Feature #1051: The first page is sometimes displayed if the app is restarted while a new intent is being loaded, Bug #1020: Unencrypted Website dialog sometimes erroneously pops up, and Bug #1069: App crashes after it has been paused and restored are all examples of race conditions introduced by ViewPager2 not always finishing creating new pages when they are expected by the rest of the app.

@Lasse Gismo, can you please test this alt build of Privacy Browser to see if it resolves the problem for you? You can install it alongside your existing Privacy Browser. The link below will expire in about a week.

https://nextcloud.stoutner.com/s/S2eqBQBZL2q5Eaq

The version in the above link has installation problems. Try this one:

https://nextcloud.stoutner.com/s/BHLZ4b9Ziw4JNKW

Installed but I'm not sure how to reproduce race condition. Been using it for a while & haven't happened yet.

I have sometimes had to use a potential change for 2-4 weeks to be sure that a race condition is fixed. You can export your settings from your main Privacy Browser into this test version and use it for a while to see if you have any problems.

A parallel installation of the test version in addition to my main PB is unproblematic?

Yes. I designed the test version so it can be installed alongside the normal version without any problem. You will have two icons, one with the word TEST across the bottom.

Soren Stoutner wrote in #note-16:

Yes. I designed the test version so it can be installed alongside the normal version without any problem. You will have two icons, one with the word TEST across the bottom.

I would rather call it beta version instead of test version, since you're trying the changes that move into the standard version.

Not just this, but you can experiment a lot of other stuff. If you felt some feature stable & polished move that into standard version. If not, keep it experimental until it matures.

Which is why I suggested you to open a beta channel & release beta version (on redmine caz fdroid would take lot of time)

There is actually an official test version that is part of every release, listed as the Alt version. It makes it easy to compare two releases side-by-side or do things like test import/export conversions between two particular versions. You can download them from:

https://www.stoutner.com/privacy-browser-android/changelog/

I might someday do a beta version, which is different from the Alt (test) version. But that is a different discussion.

Not yet able to reproduce the issue with the alt build - looks promissing.

@Lasse Gismo Your issue could be different to mine. But happened on mine
https://redmine.stoutner.com/issues/1134#note-10

That is interesting. I was expecting the change I made to fix Bug #1134: Sometimes the tab after a new tab in the middle of a list is set as active, but I wasn't sure it would fix this. Looks like it was the reverse of what I expected.

Try this updated build. It has an additional change that might make the difference.

https://nextcloud.stoutner.com/s/BxtSX3NczFQiLyc

I can't imagine any way it would make things worse. Rather, it probably has to do with the variableness of the symptoms. The increase in the behavior is much more likely to be affected by whatever is happening on your device in the background. That is often the way race conditions are.

Is there some way you could record a video of the crash? I realize this is problematic for crashes that don't occur consistently, but it might be helpful in determining what the underlying cause is.

https://gitweb.stoutner.com/?p=PrivacyBrowserAndroid.git;a=commitdiff;h=83a2b6e5635956bb940642e0e5beb47453145dc3;ds=sidebyside makes some attempts at progress on this issue, although problems remain.

There's no video required - its only a new tab with empty content and to close the tab, is to close the app.

It's a simple click on a link in Fedilab.

1. Does this ever happen when loading a link from inside the app? For example, if you long-press on a link and choose Open in New Tab. Or, if you use the + icon to open a new tab.

2. When this does happen when loading a link from Fedilab, is Privacy Browser recreated on load? You can tell if this is happening because the Privacy Browser logo will temporarily display on the screen. For context, you can check out the Android Activity Lifecycle:

https://developer.android.com/guide/components/activities/activity-lifecycle

If this is the case, you can force this to happen whenever you want for testing purposes by opening Privacy Browser, then opening 10-20 other apps (enough to force the OS to kill Privacy Browser to recover RAM), then opening a link from Fedilab.

3. Please post a copy of About > Version from inside Privacy Browser.

I believe there have to be some debugging tools for issues like these. As you said race conditions are very common. But whether handling is difficult or not I donno caz I ain't a dev.
But I've heard one can literally code an entire project with just try catch clauses is that true ?

Ok - will take care of.

But - issue only happens when there're already tabs shown, after app kill (with super freezZ) and link click there's only the new one shown and that worked/s correct.

So - not sure what to do further.

What happens if you have the OS kill the app in the background? This is different from what SuperFreezZ does (the onDestroy at the bottom of the previous graphic), because when the OS does it the saved instance state is preserved, while when SuperFreezZ does it the saved instance state is deleted. You can test this by opening Privacy Browser, then opening 20-30 other apps, then opening a link from Fedilab. You will know that you have reproduced the app kill behavior because Privacy Browser will briefly display the app logo in the center of the screen with the loading filterlists text. Then you will see all the tabs restored, and the new tab created, although my guess is that in your case the new tab is not created correctly, which is why it displays the content from the previous tab and why it ends up causing the crash when you try to close it.

Figuring out if this is what happens is very important to getting to the bottom of the problem, because the code path for opening a new tab when recreating the app after it is killed is different than the code path for opening a new tab otherwise. Figuring out which case is causing your problem leads to looking in the right place to find the fix.

If I were able to reproduce this behavior on my devices it would be easier for me to troubleshoot. But this appears to be something fairly specific to the hardware and OS you have running. So, the more information I can get from you as to what exact circumstances trigger the problem, the more likely it is that I can find a solution. This differentiating of which code path is the problem is the first important step toward narrowing this down.

OK, will stop walking my own way and follow yours - cmome back with results.

This is good because it provides us a method to test prospective fixes. It is also good because it allows me to focus my hunt for the problem. I will look into it and get back with a test build once I think I have found a solution.

@Lasse Gismo, can you try this test build and see if it resolves the problem for you? As usual, the link will expire in a few weeks.

https://nextcloud.stoutner.com/s/jiaP8ayi7EXmbFL

Looks good until now.
Will come back in a few days with results.

I don't understand what you are describing. Can you please be a little more explicit?

Tabs hang in the sense the site interface don't respond to scroll, touch, etc until I close the tabs. And it's random too.
I'm back to the previous alt build now & it doesn't happen.

I can't see any way that any of the changes in this test version could cause that type of behavior. Rather, I would imagine it has something to do with Android System WebView itself and either an incompatibility with the website you are visiting or with one of the changes you are making as root where you are redirecting directories to /dev/null.

For example, your logcat has a lot of these:

[ 01-11 06:55:47.438 32491:32491 I/auditd   ]
type=1400 audit(0.0:108921): avc:  denied  { read } for  comm="ThreadPoolForeg" name=48545450204361636865 dev="dm-4" ino=36658 scontext=u:r:untrusted_app:s0:c156,c256,c512,c768 tcontext=u:object_r:app_data_file:s0 tclass=lnk_file permissive=0 app=com.stoutner.privacybrowser.alt

And a lot of these:

[ 01-11 09:20:01.054 10056:10085 W/chromium ]
[WARNING:cache_util.cc(144)] Unable to delete cache folder.

That's strange. I've symlinked /data/data/com.stoutner.privacybrowser.alt/\
cache/WebView/Default/HTTP\ Cache to /dev/null like how standard version used to be. The recent test build #1136#note-42 has hang issues, but strangely don't have this issue on #1134#note-12 build.

Whatever is causing the problem, I can't imagine any way it relates to the changes in the code between those two versions.

@ask low, if you have made any changes to WebView DevTools recently, you might try undoing them temporarily to see if they are responsible for the behavior you are seeing.

I actually had that issue & reverted back to my last alt build, even before I messed with DevTools.
You can see my comment timings of tabs hang log & your comment of DevTools recommendation. There's an hour difference.

Infact, I'm on the alt build from #1134#note-12 with the 4 flags enabled in DevTools. Browsed for almost 4 more hours without any hangs.

I have committed the test build in #note-42 as it is likely to make progress even if it isn't the full fix. https://gitweb.stoutner.com/?p=PrivacyBrowserAndroid.git;a=commitdiff;h=70da2a558d6e35c38adb596479c36f7e451dc9a5;ds=sidebyside

However, I will leave this open until we hear back from @Lasse Gismo if this completely resolves his problem.

After 2 weeks of working with, I'll declare the described bug as fixed with that release - congrats to Soren and many thanks.