Project

General

Profile

Actions

Bug #1069

closed

App crashes after it has been paused and restored

Added by v ... 8 months ago. Updated 8 months ago.

Status:
Closed
Priority:
Next Release
Start date:
08/17/2023
Due date:
% Done:

0%

Estimated time:

Description

How to reproduce :
  1. Open a lot of tabs (15 or more, it depends on how much RAM your phone has, you can also try to open several other apps in order to reproduce it more easily) ;
  2. Switch to another app ;
  3. Go back to Privacy Browser Android ;
  4. You can see Privacy Browser is restarting and restoring all the tabs (if you previously have opened enough tabs) ;
  5. First of all, take a look at some tabs and see that some of them have been switched around, when you select a tab you will probably see the content of the tab next to the selected one (see screenshots) ;
  6. Also, often, the order of the tabs is different after tabs recovery ;
  7. Now, while closing the first two or three tabs, the app should crash ;
  8. Open the app again, you should notice that all tabs are lost.

See the attached screenshots.

See also the logcat file. The crash happened around 11:56, but I've also seen an OOM error around 11:46, so I appended it at the very beginning of the file.

This issue should probably been split into two bug issues (one focused on the crash, the other on the displayed tab metadata [title, favicon]). Here is reported the relationship between these two behaviors.

May be related :

Privacy Browser Android v3.15.1


Files

Actions #1

Updated by Soren Stoutner 8 months ago

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

Actions #2

Updated by v ... 8 months ago

  • Subject changed from App crashes after have been paused and restored to App crashes after it has been paused and restored

OK, I'll test it.

Actions #3

Updated by v ... 8 months ago

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.

Actions #4

Updated by v ... 8 months ago

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.

Actions #5

Updated by v ... 8 months ago

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.

Actions #6

Updated by Soren Stoutner 8 months ago

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.

Actions #7

Updated by Soren Stoutner 8 months ago

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.

Actions #8

Updated by v ... 8 months ago

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.

Actions #9

Updated by Soren Stoutner 8 months ago

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=

Actions #10

Updated by v ... 8 months ago

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.

Actions #11

Updated by Soren Stoutner 8 months ago

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.

Actions #12

Updated by Soren Stoutner 8 months ago

  • Status changed from New to Closed
  • Priority changed from 3.x to Next Release
Actions

Also available in: Atom PDF