Fenix: [Bug] Tabs turn into about:blank pages

[sv-ohorvath]

• [x] AC issue https://github.com/mozilla-mobile/android-components/issues/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: https://github.com/mozilla-mobile/fenix/issues/1577#issuecomment-530533172

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

[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: https://github.com/mozilla-mobile/fenix/issues/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

[softvision-miralobontiu]

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).

[karthikiyengar]

Same issue with 77.0.0-beta2. Occurs too often to the point that this version unfortunately cannot be a daily driver.

[liuche]

Is this similar to #9039 ? This didn't make the cut for 77b2 but @karthikiyengar, do you see this on the Fenix Nightly app?

[karthikiyengar]

I'm not entirely sure, here's a screencap of the behaviour

I can check the Nightlys and get back.

[liuche]

I don't think the screencap made it! it doesn't open anything for me.

[karthikiyengar]

@liuche - Updated the previous post with a GIF.

[liuche]

And do you still see this on the Nightly app?

[karthikiyengar]

@liuche - I stopped using preview for a while in favour of old firefox. I'm back on Nightly again now and will report if this reoccurs.

[karthikiyengar]

@liuche - Can confirm that it also occurs in Nightly. The behaviour is pretty much the same, with the only difference is that the URL was stuck on the previously visited website instead of about:blank

[sv-ohorvath]

This sounds like https://github.com/mozilla-mobile/fenix/issues/11501

@liuche - Can confirm that it also occurs in Nightly. The behaviour is pretty much the same, with the only difference is that the URL was stuck on the previously visited website instead of about:blank

[pocmo]

@karthikiyengar Can you go "Settings > About > Crashes" and see if there is an entry at the time you saw the white page appear? I'm curious if we detected a content process crash at this time.

From the description it is very likely that the content process crashed. By default AC will recreate a GeckoSession under the hood and it will point to about:blank. In that situation we will also set the crashed flag on the Session and allow the app to try to restore it. @sblatz's comment above (although from last year) mentions that we need to listen to that - Not sure if we ever started doing that? Otherwise the app can only detect a content process crash via the broadcast while it is in the foreground afaik.

[karthikiyengar]

Here's another gif of the behaviour if that helps.

Crashses says No crash reports have been submitted

[karthikiyengar]

Update: I've had another instance with the latest nightly where the tab still crashes with about:blank. Hasn't been picked up in the crash report.

[sv-ohorvath]

I got this similar crash in one of the automated tests: https://console.firebase.google.com/project/moz-fenix/testlab/histories/bh.66b7091e15d53d45/matrices/6411311184354138254/executions/bs.c1ebb5c4598f8ece/testcases/1/logs
The steps are:
Open 3 dot menu from the homescreen.
Go to Settings.
Go back to homescreen.
Open 3 dot menu, open the Help link.
On the Help tab, tap the tab counter.

Not sure if it's the same crash but looks similar to this bug or https://github.com/mozilla-mobile/fenix/issues/11653
From the logs:
06-22 23:58:50.543: D/GeckoSession(7710): handleMessage GeckoView:PageStart uri=about:blank

--------- beginning of crash 06-22 23:59:43.778: E/AndroidRuntime(7710): FATAL EXCEPTION: FinalizerWatchdogDaemon 06-22 23:59:43.778: E/AndroidRuntime(7710): Process: org.mozilla.fenix.debug, PID: 7710 06-22 23:59:43.778: E/AndroidRuntime(7710): java.util.concurrent.TimeoutException: android.view.ThreadedRenderer.finalize() timed out after 10 seconds

[liuche]

This is a tricky bug because it's hard to repro, but we should see if there's some situations where we lose the session state, or other root causes?

let's spend 2 days on this because it might be very difficult to figure out.

[liuche]

Could QA try to find some steps to reproduce? Thank you!

[stuarthenderson]

I can reproduce this half a dozen or so times a day on a galaxy s8. Nightly and Beta.
about:crashes doesn't show anything.

If there's anything I can do to help debug this, please let me know.

Stu

[karthikiyengar]

Just for additional context, I'm on a Galaxy S9.

[taaem]

I'm seeing this too, multiple times a week on a Galaxy S9, maybe this bug is more often triggered on Galaxy devices because of something like OOM management.

[Cheap-Skate]

I see it too but perhaps less frequently than I used to. Typically when Fenix comes to the foreground after being in background for some time. I think sometimes only the focused tab becomes about:blank, other tabs still work OK.

I am also on a Galaxy (A40) Android 10 so perhaps this is mostly a Samsung issue?

[jacktose]

I've had it a lot on Moto G5+. Bad enough that I left Preview for stable a few months ago. I'll try to replicate again on Beta or Nightly.

[stuarthenderson]

I'm not sure if this is something I've not noticed before, or a change in behaviour with more recent releases, but I've noticed if a tab gets into this bad state, if I force Firefox to close (task switcher -> swipe away) and then reopen Firefox, the tab does recover.

[Mugurell]

And just to double check, if tapping on that about:blank tab to select it from the tabs tray, the page is not reloaded anymore?

[softvision-miralobontiu]

Hi all,
I've encountered this issue today on the latest Beta build 79.0.0-beta.5 on Samsung Galaxy Tab S6 (Android 9).
I had 5 tabs opened, one of them was a radio station. Left the app in the background for an hour and a half, and when I reopen it, some tabs were blank. Tapping on one of them opened a blank page:

Here is a logcat, hope it helps:
logcat.txt

[Mugurell]

Might be of a stretch, but if someone gets to reproduce the issue, please help me in confirming the following scenario:

• [x] encounter the issue - previous websites now show about:blank or they just show a white page
  Don't try to reload, it's ok.
• [x] open a new tab with a random website.
  Opening new tabs is possible and webpages load successfully.
• [ ] try to open the contextual menu in a new tab (long press on a word in the page to get some specific options)

Does the contextual menu appears / works as expected?

[stuarthenderson]

Hit the issue with 79.0.0-beta5.

• page went to about:blank
• opened a new tab, went to a website and it rendered correctly
• long pressed a word and the contextual menu came up. Selected dictionary and it worked correctly.

Fwiw, I think there's a slight distinction between beta and nightly. With nightly, I find I can always recover the tab by forcing Firefox to close (task switcher -> swipe Firefox away) and then reopening.
This doesn't appear to work with the beta.
Stu

[Mugurell]

Thank you @stuarthenderson !
This helps eliminate a scenario I had in mind.

Still hadn't a change to get this reproduced and be able to track what's happening, I guess a long time before coming back to the app is really of the essence.

Based on Mira's logcat from above and my remembering that currently open tabs also lived in Gecko I think the issue might be there and not in Fenix/AC.
I'll investigate more on this direction.

[Mugurell]

I have another question, if someone can help:
When encountering an about:blank page,
after selecting that tab to be opened,
would pressing the back button one time result in loading the desired webpage?

Also a logcat would be of great help

[stuarthenderson]

Reproduced with 79.0.0-beta5.
Pressing back from about:blank took me to the page with my collections etc.
There were no recent, reported crashes reported on the crashes page.

Interestingly, when I came back from visiting the crashes page, the about:blank page recovered back to the previous, working state, complete with history (pressing back to me to the previous page instead of the collections page).
Stu

[stuarthenderson]

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.
Stu

[Mugurell]

Small dump of my findings following:

• Using logs I saw that whenever we are loading a new page GeckoView send us the following events:
  (here I just tapped on a top site)

  I/GeckoSession: zerdatime 188118421 - chrome startup finished
  D/GeckoSession: handleMessage GeckoView:PageStart _uri=about:blank_
  D/GeckoSession: handleMessage GeckoView:LocationChange _uri=about:blank_
  D/GeckoSession: handleMessage GeckoView:PageStop uri=null
  D/GeckoSession: handleMessage GeckoView:ProgressChanged uri=null
  D/GeckoSession: handleMessage GeckoView:PageStart uri=https://www.mozilla.org/en-US/
  D/GeckoSession: handleMessage GeckoView:LocationChange uri=https://www.mozilla.org/en-US/

• Haven't been able to reproduce the issue with about:blank IRL with normal testing but I think I managed to force it with killing the content process and so I got two instances (with 10s of tries) of tabs with the title and url being about:blank (but with the real website preview shown in tabs tray).
  In both of this cases Session.crashed was false.

• With multiple tabs in tabs tray, after killing the content process and returning to the app I could see the tabs having their title/url updated from the about:blank to what they should have. Didn't have breakpoints here, I think GV send the LocationChange followup.

• Following the above GeckoSession logs, immediately after killing the content process (something that may happen IRL and may be this issue's fuse) I see in logs that new sessions are started, again first sending about:blank and always this url being persisted on disk as the url for the tabs.
  Pastebin link (AtomicFile#writeSnapshot is seen persisting about:blank)

 
Based on the above, what I speculate is happening involves:

• while in background the content process is killed
• when it is restarted the about:blank title/url GeckoView sends us is persisted to disk for the open tabs
• for some reason GeckoView doesn't also followup with

GeckoView:PageStart uri=https://www.mozilla.org/en-US/
GeckoView:LocationChange uri=https://www.mozilla.org/en-US/

 

• Didn't see anything to be done in Fenix/AC
• I think the issue might be fixed by GeckoView not sending us about:blank as the first uri for any new session.
  This uri being sent immediately after opening a new session is the only about:blank uri that I saw possibly causing this issue.
  And I don't think we have any usecase for it in the first place..?

 
Asking @Agi since he was involved in the original ticket if he knows about why is GV sending us about:blank and if that can be avoided.

[agi90]

@Mugurell Thanks for looking at this! So if I understand correctly the theory here is that sometimes GeckoView sends a about:blank update after a crash and doesn't send the updated URL after that? or is it that the process crashes/dies _again_ after being killed in the background?

We can't really stop sending about:blank for now (it's a long story..) but the app could easily ignore them.

[agi90]

@Mugurell One thing I noticed is that Fenix reopens tabs immediately when receiving onKill: https://searchfox.org/mozilla-mobile/source/android-components/components/browser/engine-gecko-nightly/src/main/java/mozilla/components/browser/engine/gecko/GeckoEngineSession.kt#648-659

That's not correct, Fenix should only re-open tabs when the user clicks on them after the content process died, otherwise Fenix would keep restarting the content process every time the system decides to shut it down to reclaim resources wasting battery unnecessarily (until Android kills the main process directly).

I can definitely see a case where we reload a tab immediately after the content process died and then we get killed again because the system is under pressure and the app only receives the about:blank message.

[liuche]

Let's follow this suggestion then, and keep the tab closed until the user taps on it, or if the tab is the active one, reopen it once fenix comes back on the foreground (or if it's already visible).

We'll keep an eye out for reports that users want tabs to restore automatically, because that would indicate some other bug that we should fix (cc @vesta0 that GV is recommending that we don't automatically restore tabs until there is user interaction)

If this is happening bc Fenix is getting killed by Android due to memory pressure, this should also help the users' phone save battery, bc Fenix should only be killed if it's the lowest priority (and restoring may be acting like bad Android citizen, and trying to hoard resources when the phone is low).

[madb1lly]

Hi all,

Just to say I had this problem again recently when frequently switching between two tabs - one was my WebThings Gateway and the other was a Tasmota device config web page. A few tabs showed about:blank but could be restored by clicking return on the keyboard after selecting the address bar.

It happened again when restoring after a crash, the tab I did have open was about:blank and again could be restored by clicking return on the keyboard when in the address bar.

What you describe above as a fix sounds reasonable but please try and avoid anything which makes #12731 worse.

Cheers 🙂

[pocmo]

Just to say I had this problem again recently when frequently switching between two tabs

This is bug #12593 and a patch for that should come to Nightly soon.

[Mugurell]

Thank you @liuche and @agi90 !

@Mugurell Thanks for looking at this! So if I understand correctly the theory here is that sometimes GeckoView sends a about:blank update after a crash and doesn't send the updated URL after that? or is it that the process crashes/dies _again_ after being killed in the background?

We can't really stop sending about:blank for now (it's a long story..) but the app could easily ignore them.

For me it was very hard to reproduce this.
What I speculate it happens is indeed that about:blank is received and then maybe content is killed again, maybe the real url is not sent and so the session remains with that about:blank url and title. (that can even be persisted on disk for future app launches).

Not sure how to ignore them...
I understand we can be sure about blank will always be sent first and so we can ignore some / up to some events?

[pocmo]

There are two things that may be of interest here:

• For the initial load in an engine session AC already hides the about:blank load: https://github.com/mozilla-mobile/android-components/blob/master/components/browser/engine-gecko-nightly/src/main/java/mozilla/components/browser/engine/gecko/GeckoEngineSession.kt#L346-L351
• We have a similar problem when the first load is interrupted and a user presses reload (which will reload about:blank): https://github.com/mozilla-mobile/android-components/issues/7811 - https://github.com/mozilla-mobile/android-components/issues/7811

[madb1lly]

Just to say I had this problem again recently when frequently switching between two tabs

This is bug #12593 and a patch for that should come to Nightly soon.

Hi @pocmo, no I think that's a different issue which sounds like another one i raised #12382.

Above I'm specifically talking about "about:blank" not a white page.

Cheers 🙂

[pocmo]

We filed https://github.com/mozilla-mobile/android-components/issues/7820 in AC to look at not restoring immediately after the content process crashed and instead delay it until the next time the matching GeckoSession is needed.

[madb1lly]

Hi all,
Not sure if more examples help you but today i got this when unlocking my phone straight into Fenix and the page was about:blank. Pressing back restored the correct page.

Cheers 🙂

[jacktose]

I've had it a lot on Moto G5+. Bad enough that I left Preview for stable a few months ago. I'll try to replicate again on Beta or Nightly.

I tried daily-driving Beta for a couple weeks and had this issue several times.

Not that others haven't also confirmed lately, but I said I'd report back ...

[karthikiyengar]

Sorry to sound negative here, but how does one decide to ship the browser to stable, without addressing a critical bug such as this one? Multiple people have reported that this is indeed a frequently occurring issue, rendering it impossible to use Fenix as a daily driver, especially when set as the default browser for spawning web views.

[Poopooracoocoo]

This never happened on Fennec. I really thought this'd be fixed by now.

[andreicristianpetcu]

@karthikiyengar not shipping fenix = patching a really old firefox with security fixes just to throw it away in a month or two.

[jacktose]

@andreicristianpetcu Yes, that's a much better solution in the interim. Patching a stable browser until you can throw it away for a stable replacement. But I see no indication that Fenix will be a stable replacement within months.

[liuche]

Also see #12382

[madb1lly]

Hello @liuche,

I don't think #12382 and this issue are the same. The workaround for #12382 is to select the address bar and then press back, but that doesn't work for about:blank tabs.

I also don't think that #14180 sounds similar either, I never managed to correct an about:blank tab by rotating the screen and I can't find reference to anyone else fixing it that way.

Cheers 🙂

[Mugurell]

@madb1lly a potential fix for this is in https://github.com/mozilla-mobile/android-components/issues/7820
Until then, if this is happening to you, do you have any steps to reproduce, any particular scenarios in which you saw this happening? Would help us greatly!

[madb1lly]

Hi @Mugurell,

Well, ironically I find that one almost certain way to cause this is with my Mozilla WebThings Gateway homepage! ☹

This site causes Firefox on Desktop to consume a lot of CPU resources, however I don't think this is an issue with the Gateway in general but more likely my configuration of it (although I've not done any config outside of the Gateway UI, so my configuration is not particularly abnormal).

If I load this site, then leave Fenix for a while, e.g. either by switching to another tab or locking my phone, then come back later I find that the tab for this site is shown as about:blank. I don't have a "fix" for this as such, I just have to wait for several seconds and it comes back.

Other sites also show as about:blank sometimes but don't recall any repeatable cases. If I find one I'll tell you.

Cheers 🙂

[stuarthenderson]

I'd say every third time I go in, I find at least one tab is blank, or turned to "about:blank". It's making the browser pretty unusable. It reproduces basically any time Firefox has been in the background for a while.

More than happy to run a debug build or help in any other way.

Galaxy s8, unrooted, latest firmware.

[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 https://github.com/mozilla-mobile/android-components/pull/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).