[Bug] Tabs turn into about:blank pages

[sv-ohorvath]

• AC issue Do not restore immediately when GeckoSession.ContentDelegate.onKill() is getting called android-components#7820

Steps to reproduce

This is similar or the same as #1577.
Logged it based on @agi90 comment on Slack and one other user reports that it still sees this issue: #1577 (comment)

Expected behavior

Tabs show pages.

Actual behavior

Tabs turn into about:blank after a while, with no history saved.

Device information

• Android device:
• Nightly 190910 18:03 (Build #12531808)
  📦: 12.0.0, 9fecd17d3
  🦎: 71.0a1-20190909095540

┆Issue is synchronized with this Jira Task

[pocmo]

I wonder if this was a process kill or a crash. 🤔

And I'm also curious whether the tabs restored when selecting them?

Also see this issue: #3170 - I think we are not really handling situations where tab(s) crash while we are not in the browser screen yet (We do not look at Session.crashed? CC @sblatz)

[agi90]

And I'm also curious whether the tabs restored when selecting them?

for me, they didn't. When I clicked on them about:blank opened.

[sblatz]

@pocmo I believe that's correct, yes. I'm going to put a needs group triage on this so we can make sure it's visible to product.

[sblatz]

Confirmed in group triage that this is a high priority bug. Let's listen to the AC hook that Sebastian mentioned 😄

[vesta0]

This is a GeckoView bug but we can potentially fix it in AC.

[darkwing]

In the similar bug, @liuche said:

Once one tab crashes, since we don't have E10S multi-process, anything that shares that process will crash because we can't fix this until GV gets this in Q2 2020. So we'll close it for now.

Wouldn't that affect this as well? What is the hook that @sblatz mentioned?

[BranescuMihai]

@darkwing my guess is that he was referring to Session.crashed boolean, maybe we should check this variable for all sessions when we come back to the app from background, and if they are indeed crashed, then use something like requireComponents.useCases.sessionUseCases.crashRecovery.invoke()

I tried reproducing it by going to about:crashparent to trigger a crash, and after app restart, the tab that was selected becomes indeed about:blank, but the crashed boolean for that session is false.
Using about:crashcontent, the tab crashes and the crashed boolean was true and session is recoverable, so probably crashed is not saved with the session state

Sidenote: process kill for the tab, the app or both does nothing for me, the tabs are recreated correctly, so my guess is the problem comes from a crash

[lobontiumira]

Hi!
I encountered this issue after accessing about:crashcontent, restart the app, all the other tabs were blank on Nightly build from 2/13 with Sony Xperia Z2 (Android 6.0.1).

[Cheap-Skate]

I just had this same issue, the tabs are all about:blank and tapping on a tab doesn't bring back the actual page.

I think it happened after Fenix was killed by the Android memory manager:- I was doing other stuff on my phone, went back to Fenix, Fenix opened on the tabs tray, everything was about:blank.

Galaxy A40, Android 9.0.0, today's Fenix Nightly.

[madb1lly]

I had this issue shortly (hours) after migrating from Fennec to Fenix. I didn't close Fenix, but after a few hours I came back to it and several (but not all) of my tabs had turned into about:blank tabs with no way to recover them (no history left in the tabs).

[nyanpasu64]

do you have any steps to reproduce, any particular scenarios in which you saw this happening? Would help us greatly!

I found a semi-consistent way to turn tabs into about:blank or empty tabs.

• In Firefox, open any page.
• Open Android "Developer options", scroll to the "Apps" heading (the bottom-most heading).
  • Enable the first option (Don't keep activities). If you disable this, Firefox will unload/reload, but tabs won't turn blank.
  • Change the second option (Background process limit) to "No background processes" to unload Firefox when switching apps.
• Switch apps, wait for 1-2 seconds to let Fenix unload. Then switch back to Fenix.

Actual behavior

This bug only triggers randomly.

Moto G5 Plus, Nightly

Tab has the right URL, but displays a white screen. Switching to other tabs causes them to display a white screen as well, and the thumbnail to turn white. Reloading any tab causes the progress bar to appear and disappear quickly, and the page remains white. Focusing the address bar and pressing Enter fixes the issue.

I think (not 100% sure) this is different from #12593, because in that bug, switching tabs fixes the issue.

Samsung SM-T510 tablet, Firefox

The focused tab will have the right URL, but display a white screen (white thumbnail). The previous tab has a URL of about:blank, with a white screen, but the proper thumbnail. Refreshing does nothing (no progress bar appears). Pressing Enter in the address bar does nothing.

Saving all tabs in a collection, closing all tabs, then reloading the collection, partially resolves the problem. The first tab you activate loads properly. The second tab you activate loads to a white screen, where refreshing is a no-op (progress bar sometimes flickers for a very short time), but pressing Enter in the address bar fixes the issue.

Samsung SM-T510 tablet, Firefox (take 2)

Instead of a tab, the tab tray appears. Some tabs load, others are white screens. All have the proper URL and are fixed by pressing Enter in the address bar (but not reloading).

Saving all tabs in a collection, closing all tabs, then reloading the collection, does not help. The tabs that loaded still load, and the tabs with a white screen are still a white screen exactly like before.

Samsung SM-T510 tablet, Nightly

Active tab turns into about:blank with a white screen. One other tab loads, and another tab has the right URL but a white screen.

Reloading "URL + white screen" turns it into a dark screen (I'm on dark theme). Pressing Enter in the URL bar fixes it.

Navigating away and back to about:blank causes the issue to spontaneously fix itself. In previous runs, I've seen it load on about:blank and fix itself within 1 second, or fix itself after tapping the URL bar.

Saving all tabs in a collection, closing all tabs, then reloading the collection, causes all tabs to load except for "URL + white screen" which behaves exactly like before.

(Nightly recently changed the Collection UI. I dislike how no tabs are selected by default, for the use case of "save all tabs before I close them". I like how you check them in the existing tab tray. I dislike how the tabs are saved/restored in the order of your taps, not the original order... even though tap order is not indicated on the UI.)

(EDIT) Samsung SM-T510 tablet, Git build

I got a tab with the right URL in the address bar. However, it behaved more similarly to about:blank, in that pressing Enter in the address bar did not load the page, but switching to a different tab and back did.

I redid the test, got an about:blank tab after a few iterations. Link to logcat (taken at INFO level).

One more observation (apologies for the spam), I've found I can recover an "about:blank" page by swiping it away and then hitting "undo" to recover it again.

This does not work for "URL present" tabs where pressing Enter in the URL bar doesn't work.

(EDIT) Potential root causes

On m SM-T510 tablet, on all 3 browsers, I checked the About dialog's crash listing. I do not see any crashes that occurred during the same time as my tests.

Device information

Moto G5 Plus on Android 8.1.0:

• Nightly 200829

Samsung SM-T510 on unofficial LineageOS 9:

• Nightly 200830
• Firefox 79.0.5

[Cheap-Skate]

Just FYI I haven't had this issue for a long time, maybe several months. I used to get it a lot. Galaxy A40, today's Fenix.

[nyanpasu64]

The "Don't keep activities" checkbox causes significant changes in Fenix's behavior when you navigate away from the app. I discovered this by running my self-built Firefox Preview, connecting my tablet to Android Studio, then taking logcats at Debug level, but filtered to messages containing geckosession.

"Don't keep activities" unchecked (activities survive closing Fenix)

Going to the Android home screen causes Fenix to fully shut down (though with some noisy errors). Logcat at https://gist.github.com/nyanpasu64/f32e9c5899e6033a0d36d70b454ac4df#file-keep-activities-press-home (I only took logcat once)

"Don't keep activities" checked

Going to the Android home screen causes Fenix to enter an endless loop of zerdatime 3026051 - chrome startup finished and Attempted to close a GeckoSession that was already closed., with a period around 3 seconds. Logcat at https://gist.github.com/nyanpasu64/f32e9c5899e6033a0d36d70b454ac4df#file-don-t-keep-activities-press-home-2 (I took many logcats, all exhibiting this pattern.)

At first, you may get one or two Attempted to close a GeckoSession that was already closed., followed by a matching number of zerdatime ###### - chrome startup finished. Afterwards, they alternate. If you press the Fenix app icon right as a GeckoSession message appears, the active tab always loads properly. If you press the Fenix app icon right as a zerdatime message appears, the tab always turns into about:blank. If you press the Fenix app icon about 1 second after a zerdatime message appears, the tab has turns into "URL + white screen".

Crash

One time, on each cycle, zerdatime was followed 400ms later with a GeckoSession message. Pressing Fenix as soon as zerdatime appeared caused the app to crash.

b3452f12-a3c1-4e2a-81de-1af8007f68ff
<native crash>
 * Socorro: https://crash-stats.mozilla.org/report/index/bp-b7d80c0a-1df9-4c46-95aa-138ba0200830
----
<native crash>

The link is https://crash-stats.mozilla.org/report/index/bp-b7d80c0a-1df9-4c46-95aa-138ba0200830.

Zombie

I forgot how I entered this state... I think I swiped the browser from my recent apps, after opening the Socorro link.

I got Firefox into a state where existing tabs don't load... and new tabs don't load any pages either. I get no GeckoSession logcat entries at all when trying to navigate pages. Swiping the browser from my recent apps didn't help, only force-stop did.

[nyanpasu64]

What causes the logcat messages?

I took some notes at https://docs.google.com/document/d/1jx80AjOFmDRUpr5ePtBawwK5oXA_zEZWqbRRH5h7_uo .

My "Developer options" reproduction mechanism produces unusual log messages. I think they are caused by repeated "GeckoView:ContentKill" messages from an unknown source to GeckoSession.

Switching away from Firefox causes Firefox to reload

I decided to run some experiments on my Moto G5 Plus phone, using a "normal" Android environment with "Don't keep activities" and "Background process limit" set to their default values. I was unable to reproduce about:blank or unloaded tabs, but did discover strange behavior:

Switching away from Firefox would usually cause only a single handleMessage GeckoView:StateUpdated uri=null message. However it would occasionally produce a single Attempted to close a GeckoSession that was already closed. and zerdatime 765355200 - chrome startup finished message, followed by reloading about:blank and the original URL. Logcat at https://gist.github.com/nyanpasu64/d4206f4eaae11172dc7ac8afaed2d99b .

I tried switching back to Firefox after seeing zerdatime, but was unable to cause the page to remain on about:blank and fail to load the proper URL.

I tried running this experiment again with a debugger, and found that this reloading behavior was triggered by a "GeckoView:ContentKill" message in the wild, just like my synthetic environment.

[madb1lly]

Hi all,

I think it's worth opening a new [Meta] issue to capture all the different flavours of this bug, including this one, #12382 and #14180 and any other relevant ones. Whilst the cause (and the fix) may be the same, the symptoms are different which means that the fix may not be the same.

FWIW I can add micromag.cc to the list of sites which always show as the "URL+white screen" bug (#14180 - that bug should really not have been closed) and github.com is sometimes in this category but not always.

To revive from the "URL+white screen" state I need to press return in the address bar or force refresh; normal refresh is not guaranteed to work.

Cheers 🙂

[bgibney3]

Samsung Galaxy s20+ 512GB
Unlocked, not rooted
Android 10, Aug. 5th 2020 security update

79.0.5 (Build #2015758619)

tl;dr clearing 100k addresses from browsing history banished this bug for me

I debated saying anything, but saw this bug was still open after a long time, so...

This about:blank issue was constant for me on upgrading. Every other time I left 79.0.5 running in the background and came back to it, I would be presented with most or all tabs displaying about:blank, and I would be unable to recover them, despite all the tricks listed in this and linked issues. I'd end up closing all tabs. It happened every time I left even a dozen tabs open overnight.

Here's the thing, it stopped happening two days ago. What changed?

The only thing that changed is I finally broke down and deleted "Browsing history and site data", which had been accumulating (in Fennec) for five months up until then. At the time I cleared it, there were 110,000+ addresses.

I'm not knowledgeable enough to begin verifying if browsing history is even possibly related, but I can state without hesitation that's the only change in my install/profile. I had no outward evidence of crashes, duplicate tasks, hangs, etc. related to this use case. No private tabs usage, no PWA, tabs could have been opened from collections, bookmarks. Never messed with "don't keep activities".

Curious if others who consistently experienced this also had the habit of only deleting cache and/or cookies, but keeping browsing history for weeks or months. I mean, I can't be the only one, right?!

Tough to reproduce in a hurry, I know 🙄

[stuarthenderson]

I can confirm that with "Don't keep activities" checked, as suggested by @nyanpasu64 , I also don't get the about:blank issue... obviously not a solution, but an interesting data point.

I tried clearing my browser history, as suggested by @bgibney3 , and this does seem to make the issue less frequent, but doesn't get rid of the issue entirely for me.

Stu

[liuche]

AC mozilla-mobile/android-components#8320 has landed, should be in the next nightly

But we will likely continue investigating/figuring out what's going on.

[sflorean]

Tested on Nightly 9/10 following the steps provided in this bug and we couldn't reproduce the issue. We did encounter about:blank page on Huawei P20 lite, A9 (tab was opened for more than 1 day and refresh wasn't working) but we couldn't reproduce it anymore.
Devices used:

• Nokia 6 (Android 7.1.1)
• Samsung Galaxy Note 10 (Android 10)
• Google Pixel 3 (Android 11)

@liuche should we close this bug and follow up on other related?

[stuarthenderson]

Did the fix go in on the nightly 9/9 or 9/10? as I managed to reproduce the issue on 9/9 (Galaxy S8, stock).
Nothing so far on 9/10.

Stu

[nyanpasu64]

On the 9/11 build of Nightly. I set "Don't keep activities" enabled and "Background process limit" to "No background processes". In this setup, switching away from Firefox used to cause Firefox to enter the 3-second loop. It no longer happens; I instead get:

09-11 04:52:27.518  9179  9179 D GeckoSession: handleMessage GeckoView:StateUpdated uri=null
09-11 04:52:27.894  9179  9179 W GeckoSession: Attempted to close a GeckoSession that was already closed.

And no further zerdatime messages until I reopen Nightly.

I haven't gotten about:blank yet either.

[madb1lly]

Hi all,
Still present on Nokia 8, Android 9, Nightly 200909 06:00 (Build #2015762867)
AC: 58.0.20200907130126, dc4efe6c5
GV: 82.0a1-20200906094118
AS: 61.0.13

Transferwise.com/fr

Happened on app resume after a few minutes.

Cheers 🙂

[stuarthenderson]

I've not seen the issue for 72 hours now, having previously had the issue multiple times a day. Starting with the build on the 10th.

Might be premature to say it's fixed, but it's certainly at least a lot better. Thanks folks! I appreciate the effort!

Stu

[karthikiyengar]

I'm also very happy to report that I haven't encountered this issue with the nightlies on my Galaxy S9. Thanks a lot for all the effort and I'll update if the issue reoccurs.

[pocmo]

Closing this one as fixed. I'll keep #15046 open which is another way to trigger about:blank (content process crashing while the app is in the background).