979899 - Regression: Swiping away FxAccountStatusActivity will disable all widget UI in GeckoPreferences back in the browser

Status: RESOLVED INCOMPLETE

(Firefox for Android Graveyard :: General, defect, P5)

Description

[Aaron Train [:aaronmt]]

Currently in Nightly (03/05), when one swipes away an active FxAccountStatusActivity from Android's recent application listing, and then returning back to the browser, all accessible widget UI becomes disabled.

This does not happen when tapping the directional arrow in the top left corner to return from FxAccountStatusActivity back to GeckoPreferences

--
Nightly (03/05)
Samsung Galaxy SIV (Android 4.4.2)

Comment 1

[Aaron Train [:aaronmt]]

This resolves by hitting back (returning to the browser) and then re-entering GeckoPreferences (Settings).

Comment 2

[Nick Alexander :nalexander [he/him]]

I saw this once when testing against Android 2.3.6; it manifested itself as the menu no longer responding.  Presumably we're doing something wrong with the Activity/Fragment onPause cycle. rnewman, do you have any thoughts?

I will investigate this ASAP because this is a ship-blocker for the new StatusActivity from my perspective.  I wonder if this was an issue with the old StatusActivity?  More to come on this ticket.

Comment 4

[Richard Newman [:rnewman]]

Three hypotheses:

* It's a bug in GeckoPreferences' activity lifecycle.
* It's a bug in Android's handling of the activity lifecycle.
* It's a bug in the preferences UI system.

Comment 5

[Aaron Train [:aaronmt]]

(bug 974134 was aurora+'ed, so going to mark this as 29 affected)

Comment 6

[Aaron Train [:aaronmt]]

Ah this is reproducible w/o bug 974134 on 29 regardless.

Comment 7

[Nick Alexander :nalexander [he/him]]

(In reply to Aaron Train [:aaronmt] from comment #6)
> Ah this is reproducible w/o bug 974134 on 29 regardless.

This is really valuable, thanks so much.  (I'll verify, but this is the first thing I wanted to understand.)  This suggests that the unknown rat's nest of new PreferencesFragment code is not the issue; but instead, there are Activity lifecycle issues between GeckoPreferences and its child activities.

Investigation proceeding today.

Comment 8

[Richard Newman [:rnewman]]

Nick, can you assign this to someone else or give a status update?

Comment 9

[Nick Alexander :nalexander [he/him]]

(In reply to Richard Newman [:rnewman] from comment #8)
> Nick, can you assign this to someone else or give a status update?

Status update is I haven't had time to look at it.  I expect this has nothing to do with FxA per se, and something to do with spawning activities from GeckoPreferences, so I would expect any front end dev to be able to make progress investigating.

Comment 10

[Nick Alexander :nalexander [he/him]]

Initial findings:

This is related to setting FLAG_ACTIVITY_NEW_TASK at:

http://mxr.mozilla.org/mozilla-central/source/mobile/android/base/preferences/SyncPreference.java#39

If we add that flag and launch the Sync 1.1 activity instead, we get the same (buggy) behaviour when killing the task via the launcher.  Since we don't currently start a new task for Sync 1.1, we don't see this behaviour.

Comment 11

[Richard Newman [:rnewman]]

See Bug 965020 (derived from Bug 964883).

I'd love for things to work if we take it out, but I probably added it for a reason.

I guess the interesting question here is why GeckoPreferences doesn't resume correctly when its task is restored.

Comment 12

[Nick Alexander :nalexander [he/him]]

(In reply to Richard Newman [:rnewman] from comment #11)
> See Bug 965020 (derived from Bug 964883).
> 
> I'd love for things to work if we take it out, but I probably added it for a
> reason.

It does -- technically -- work if the flag is removed, but the new task behaviour is actually desirable.

> I guess the interesting question here is why GeckoPreferences doesn't resume
> correctly when its task is restored.

That appears to be a little involved.  Everything seems fine with the Activity and Fragment lifecycle, save that the GeckoPrefs invocation called by the second Activity.onCreate (the one setting up the Preferences Activity after swiping away) never gets the Preferences:Data message.  Clearly, there's an issue with adding/removing/triggering a fresh Preferences:Get message.  So it appears to be more that GeckoPrefs is fragile or not used correctly, rather than GeckoPreferences itself.

Comment 13

[Richard Newman [:rnewman]]

I suspect this is related (if only by lifecycle siblinghood) to Bug 949495, because the rehydrated browser exhibits that bug.

Adding a bunch of logging shows that after the resume we've got a new EventDispatcher, at least.

Comment 14

[Richard Newman [:rnewman]]

Ah, Gecko not running, and BrowserApp (and ancestors) not expecting anyone else to have run before them.

03-24 19:02:54.388  6967  6967 I GeckoEventDispatcher: Registering Preferences:Data.
03-24 19:02:54.388  6967  6967 I GeckoEventDispatcher: Registered Preferences:Data.
03-24 19:02:54.388  6967  6967 I GeckoPreferenceFragment: Request is 1

...
  hit Back to launch BrowserApp:
...

03-24 19:04:14.748  6967  6992 I GeckoEventDispatcher: EventDispatcher got {"type":"Preferences:Data","requestId":1,"preferences":[]}
03-24 19:04:14.748  6967  6992 D GeckoPrefsHelper: Preferences:Data message had an unknown requestId; ignoring

Comment 15

[Richard Newman [:rnewman]]

Attachment: Straw-man patch to show partial initialization in GeckoPreferences.

I started hacking away until I got GeckoPreferences to load prefs on resume. As I mentioned in an earlier comment, the issue is that Gecko isn't running, and thus isn't listening for the prefs fetch until you trigger it to load by opening the browser.

Note that hitting "Back" to get to BrowserApp will now cause a crash, because BrowserApp didn't set up the viewport, but GeckoAppShell et al report themselves as initialized.

This cuts to some of the same issues in Bug 969637 -- GeckoApp et al assume that they're going to be the first activity to come to life, and thus init of Gecko is intimately tied to the browser, despite it being quite possible to enter Fennec in a non-browser Activity.

That we need to do all of the crap in this patch, complete with lying about a LayerView, makes me very sad -- there should be no reason why we can't pass a headless Gecko around. My guess is that snorp is working on that. If those improvements won't be ready in time, we need to proceed with the core of this patch.

Comment 16

[Nick Alexander :nalexander [he/him]]

> That we need to do all of the crap in this patch, complete with lying about
> a LayerView, makes me very sad -- there should be no reason why we can't
> pass a headless Gecko around. My guess is that snorp is working on that. If
> those improvements won't be ready in time, we need to proceed with the core
> of this patch.

I disagree that we want to hack around this.  This just isn't that big a deal, yet. Lots of Android devices don't even allow you to do this "swiping" away.  We only launch one or two activities from GeckoPreferences, and only this one is launched as a separate task.

So I'd gently suggest that we want to address the underlying issues on a reasonable time frame, and mitigate here, or ignore, depending on the pain of the underlying issues and the hacks in your patch (which I am pointedly not looking at tonight).

Comment 17

[Richard Newman [:rnewman]]

(In reply to Nick Alexander :nalexander from comment #16)

> I disagree that we want to hack around this.

Broadly I concur. Mentally couch my statements as "assuming we consider this worth fixing".

> Lots of Android devices don't even allow you to do this "swiping"
> away.

Bear in mind that this will also bite if you task switch and the activity has been killed, I think.

Comment 18

[Richard Newman [:rnewman]]

Slipping this to 30, 'cos it won't get done.

Comment 20

[Brad Lassey [:blassey] (use needinfo?)]

filter on [mass-p5]

Comment 21

[Firefox Bug Husbandry Bot]

Re-triaging per https://bugzilla.mozilla.org/show_bug.cgi?id=1473195

Needinfo :susheel if you think this bug should be re-triaged.

Comment 22

[BMO Automation]

We have completed our launch of our new Firefox on Android. The development of the new versions use GitHub for issue tracking. If the bug report still reproduces in a current version of [Firefox on Android nightly](https://play.google.com/store/apps/details?id=org.mozilla.fenix) an issue can be reported at the [Fenix GitHub project](https://github.com/mozilla-mobile/fenix/). If you want to discuss your report please use [Mozilla's chat](https://wiki.mozilla.org/Matrix#Connect_to_Matrix) server https://chat.mozilla.org and join the [#fenix](https://chat.mozilla.org/#/room/#fenix:mozilla.org) channel.