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)

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

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.

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.

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

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

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

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

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

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.

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.

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

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.

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

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.

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

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

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

filter on [mass-p5]

Re-triaging per https://bugzilla.mozilla.org/show_bug.cgi?id=1473195 Needinfo :susheel if you think this bug should be re-triaged.

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.