Privacy Browser Android

Since the last release, I have refactored the page switching code. It was to address Bug #1020: Unencrypted Website dialog sometimes erroneously pops up, but it might have a large impact on this as well.

https://gitweb.stoutner.com/?p=PrivacyBrowserAndroid.git;a=commitdiff;h=6f53fabebc2ce78292a268e6ad0712dec8b6f3d9

Can you install a debug build that contains this change and see if you are still having issues? The APK below is the Alt version. It will install next to your existing Privacy Browser. If you like, you can export and import settings between them. The link expires after a few days.

https://nextcloud.stoutner.com/s/9SmeJB4PAmkF2Lg

This bug is not so easy to reproduce (when one is focusing to reproduce it). I had to try several times, loading several apps, switching between them, hoping Android will pause them, and closing two or three tabs to check if Privacy Browser will crash.

When I succeeded to reproduce it, I got this same error message, initially reported here.

FATAL EXCEPTION: main
Process: com.stoutner.privacybrowser.standard, PID: 17587
java.lang.NullPointerException: null cannot be cast to non-null type android.widget.FrameLayout
    at com.stoutner.privacybrowser.activities.MainWebViewActivity.closeTab(SourceFile:157)

However, while testing the "alt debug" (test) version you provided, I was not able, even trying hard, to reproduce the two described problems (selected tab not related to displayed content + app crash after paused and restored then closing two or three tabs).

So, it seems to be a good news.

The crash seems only to occur when I'm closing a tab displaying the content of another tab. I suppose that's what has been fixed.

Also see the initially uploaded screenshot where the tab title and content are OK, but not the favicon. Don't know if it is a side effect of the same problem. I remember I clicked on the Invidious link, then went back. But don't remember if the app has been paused and restored.

Yes, the core of this problem was something I encountered myself, but it was very hard to duplicate. Sometimes I would have to try for several weeks to replicate it to see if a fix had actually been applied. Basically, with the switch from ViewPager to ViewPager2 in 3.15.

https://www.stoutner.com/privacy-browser-android-3-15/

Google had deprecated ViewPager and was really leaning hard on people to make this switch. But it resulted in a lot of subtle and difficult to reproduce breakage because a lot of things that used to happen in order now happen asynchronously, which is why some tabs would get restored (or at least display) with the wrong information and some views that Privacy Browser could previously assume were populated might not be (leading to the crash you observed). Refactoring the way the app moves between tabs has mitigated a lot of this undefined behavior, although there is still at least one bug (Feature #1051: The first page is sometimes displayed if the app is restarted while a new intent is being loaded) that is outstanding.

The real question is if this crash is common enough that I should do a point release now, or if it is uncommon enough that I should just wait until 3.16 is ready.

Personally I don't often have a lot of tabs open for a long period of time (I usually run Clean and Exit almost every time I have finished reading a page). I assume that most users of Privacy Browser behave similarly. As such, I have had to modify my behavior to even test this bug. If most users are like me it is unlikely that many people will encounter this bug.

I'm used to open a lot of tabs, not all the time, but often.

Personally, I can wait until you release v3.16. I just have to not close any tab after a pause+restore, I'm used to.

For a sense of timeline, I am currently spending most of my time on implementing bookmarks in Privacy Browser PC (#968). When that is done I will release Privacy Browser PC 0.5 and then begin working on the 19 items still outstanding for Privacy Browser Android 3.16.

https://redmine.stoutner.com/projects/privacy-browser/issues?utf8=✓&set_filter=1&sort=id%3Adesc&f%5B%5D=status_id&op%5Bstatus_id%5D=o&f%5B%5D=priority_id&op%5Bpriority_id%5D=%3D&v%5Bpriority_id%5D%5B%5D=4&f%5B%5D=&c%5B%5D=tracker&c%5B%5D=status&c%5B%5D=priority&c%5B%5D=subject&c%5B%5D=assigned_to&c%5B%5D=updated_on&group_by=&t%5B%5D=

v ... wrote in #note-4:

The crash seems only to occur when I'm closing a tab displaying the content of another tab. I suppose that's what has been fixed.

Some additional information about that. What I've described in this quote happens almost, or maybe always, if there are empty tabs (titled "New tab"). The empty tab is showing the content of the tab on its left, and the tab on its left is showing an empty content, of the empty tab.

This was caused because there was an asynchronous disconnect in the way tabs and the (pragmatically totally separate pages) were restored. The tabs and the pages act like they are connected in Privacy Browser, but this is a mirage. The operate separately and are connected with a number of public callbacks. Previously, changing the tab would change the page (and set the current WebView, which controls which WebView thinks like the URL bar and the options menu operate on). Also, changing the page would change the tab (which was a relic of when I was trying to allow swiping between tabs in the WebView).

This worked reasonably well with ViewPager, but had many problems in ViewPager2, where things became much more asynchronous. Particularly if you restored a page with content and then afterward restored a page with no content (no URL loaded). The first one would start, then the second one would start and finish (switching focus to it and its tab) while the first one was still going. This focus switching during restart could lead to a lot of undetermined behavior.

While working on #1020, I realized that there was no good reason to maintain the ability for a page to select a tab. So, I reworked the whole system so that all selection of pages comes from tab activity, and there is no feedback loop that can go the other direction. This simplifies the entire process of restoration, and seems to have resolved a number of seemingly unrelated issues.