Fenix: FNX-5113 ⁃ [Bug] Fenix doesn't handle content process dying

Created on 11 Apr 2019 · 39Comments · Source: mozilla-mobile/fenix

Steps to reproduce

Load a page in Fenix Debug

Simulate device killing content process:

connect to device adb shell
$ run-as org.mozilla.fenix.debug
Get :tab process id: $ ps -A | grep org.mozilla.fenix.debug:tab
Kill process $ kill -9 <PROCESS ID>

Note: This is really common, especially on lower-end android devices.

Expected behavior

Pages refreshes and keeps state as much as possible

Actual behavior

Fenix navigates to about:blank

Device information

Android device: Samsung S10e
Fenix version: latest from playstore

P1 crash ac 🐞 bug

Source

agi90

👍1

Most helpful comment

We did it folks!!

Thanks to all who worked on resolving this! 🎉

yay

sblatz on 9 Aug 2019

🎉6

All 39 comments

I think the problem here is that Fenix doesn't handle ContentDelegate.onCrash properly, the app is responsible for restoring the state if the content process is gone.

agi90 on 25 Apr 2019

Submitted an a-c patch here: https://github.com/mozilla-mobile/android-components/pull/3170

sblatz on 29 May 2019

After a conversation with @pocmo it sounds like this is actually a GV issue. The engine is not properly notifying a-c of a process death and thus we're not getting a crash sent to us on the Fenix side.

Sebastian filed a GV bug here: https://bugzilla.mozilla.org/show_bug.cgi?id=1557096

sblatz on 5 Jun 2019

@vesta0 this will now be blocked on GV. How would we like to proceed?

sblatz on 5 Jun 2019

Good to know, thanks @sblatz

@bifleming FYI let's track this GV bug.

vesta0 on 5 Jun 2019

FYI @vesta0 I know we won't be able to get a fix in by MVP because the linked bug needs GV (and probably then AC) work, but the bugs that likely happen because of this are pretty severe (see #3414) and we should probably prioritize these fixes when planning post MVP work

ekager on 14 Jun 2019

Note that this also causes CustomTab to go into a weird state where it has a URL bar on top (!) but it points to about:blank and the user cannot really do anything about it.

agi90 on 14 Jun 2019

FYI @vesta0 I know we won't be able to get a fix in by MVP because the linked bug needs GV (and probably then AC) work, but the bugs that likely happen because of this are pretty severe (see #3414) and we should probably prioritize these fixes when planning post MVP work

Fully agree with @ekager here. I would even consider pushing out a 1.0.1 just for this issue - as soon as we have a fix.

pocmo on 14 Jun 2019

@agi90 @pocmo thanks for the recommendation, let's ship this fix as soon as it's ready.

vesta0 on 14 Jun 2019

Are we considering release noting this issue for the MVP? I hit it again on my Pixel and I think end users might be a bit confused when they see it happen.

mozillamarcia on 14 Jun 2019

👍1

Alvina has a GV patch up for review, but I don't have an ETA.

https://bugzilla.mozilla.org/show_bug.cgi?id=1557096

cpeterso on 18 Jun 2019

This landed in GV and I am removing the "needs:gv" label. The next step is to now take that over in AC - tracked here:
https://github.com/mozilla-mobile/android-components/issues/3310

pocmo on 16 Jul 2019

The GV fix was backed out for causing some test failures, so this Fenix issue still need the "needs:gv" label.

cpeterso on 17 Jul 2019

@cpeterso are there plans to resolve that or is it not high priority?

sblatz on 17 Jul 2019

@cpeterso are there plans to resolve that or is it not high priority?

It's a high priority. The test failures were unrelated to the GV fix, so we should be able to re-land soon.

cpeterso on 18 Jul 2019

That's great news. @cpeterso can you please comment here and unlabel this waiting when that fix lands? :)

sblatz on 19 Jul 2019

Still waiting. The GV fix landed in GV 70 Nightly. It will get uplifted to GV 69 Nightly (the version Fenix will use next) in a couple days.

cpeterso on 21 Jul 2019

👍1

The implementation for this landed in AC for GeckoView Nightly. Once this lands in GeckoView Beta we uplift this to our beta component too. This work is tracked by the following issue:
https://github.com/mozilla-mobile/android-components/issues/3877

pocmo on 23 Jul 2019

@pocmo just making sure you know the GV bug was fixed...

bifleming on 26 Jul 2019

@pocmo just making sure you know the GV bug was fixed...

The GV bug is fixed in GV 70 Nightly, but hasn't been uplifted to GV 69 Beta yet. There are some patch problems that the engineer needs to fix first.

cpeterso on 27 Jul 2019

Yeah, still waiting for the 69 uplift.

pocmo on 29 Jul 2019

Looks like the most recent comment on bugzilla has an "uplift" tag. Does that mean this is ready? @pocmo, @agi90?

sblatz on 2 Aug 2019

Well the tag doesn't necessarily mean that, but looks like this latest uplift attempt was successful! The code will be in the next beta build.

agi90 on 2 Aug 2019

The code will be in the next beta build.

btw, the next GV 69 Beta build will be available on Tuesday August 6.

cpeterso on 2 Aug 2019

The code will be in the next beta build.

btw, the next GV 69 Beta build will be available on Tuesday August 6.

Correction: pocmo just kicked off a new GV 69 Beta build, which should be available in a couple hours:

https://maven.mozilla.org/?prefix=maven2/org/mozilla/geckoview/geckoview-beta-arm64-v8a/

cpeterso on 2 Aug 2019

I think now that the GV build includes the fix we are now just waiting on mozilla-mobile/android-components#3877

ekager on 5 Aug 2019

This is included in our engine beta component now (latest A-C 8.0.0-SNAPSHOTs).

csadilek on 8 Aug 2019

🎉1

I will test this manually tomorrow 😄

sblatz on 8 Aug 2019

We did it folks!!

Thanks to all who worked on resolving this! 🎉

yay

sblatz on 9 Aug 2019

🎉6

GV bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1557096

cpeterso on 9 Aug 2019

Amazing work, thank you 💯

vesta0 on 9 Aug 2019

🎉1

This appears to have been fixed in v1.3.0-rc1, but regressed in v1.3.0-rc2 and 3 (or at least the symptom has).

stuarthenderson on 19 Aug 2019

@stuarthenderson could you give more details about what you're seeing in v1.3.0-rc3 related to this bug?

ekager on 19 Aug 2019

Same symptom as before. I'd been using rc1 since it appeared on taskcluster without issue. Yesterday i tried rc2 and noticed one of my tabs got set to "about:blank". It happened again an hour or two later. I noticed rc3 today and tried that, but it happened again.

Happens when i navigate away from Preview for a bit (using other apps) and when you go back occasionally one or more of the "tabs" are at "about:blank".
The fix is definitely working some of the time, as I see tabs flickering to a:b and back to normal most of the time.

I think each time it was the last used tab that goes to a:b.

stuarthenderson on 19 Aug 2019

Did you open the tab?

I just had one case where two of four tabs became about:blank, then restored when I opened the tab.
On Nightly 190818 18:02 (Build #12301810)
📦: 8.0.0, 78354bc12
🦎: 69.0-20190812090043

IdmFoundInHim on 19 Aug 2019

Ah! You're right. It does eventually recover when you select the tab. Thanks!
So it's functional, but looks a bit bad.
Might be a good idea to block the list of tabs from showing "about:blank" in such cases, but probably not within the scope of this ticket.
Thanks all.

stuarthenderson on 20 Aug 2019

I think what you might be seeing is a variant of #3846. Currently the tabs tray does not seem to update automatically whenever the tabs/Session changes: The tab is already restored but the tab tray is showing the old state until you switch to it.

pocmo on 20 Aug 2019

Still seeing .. This or something like this on occasion.

Usually, after I open a bunch of new tabs (click a link and open in new tab), switch tabs a few times and then switch apps..When I come back to fenix, it has been killed by this os and I get this:

Screenshot_20190911-153217