1184993 - Enabling Wifi during Email setup closes app

Status: RESOLVED WORKSFORME

(Firefox OS Graveyard :: General, defect)

Description

[Peter Bylenga [:PBylenga]]

Attachment: WifiConnectEmailSetup_log.txt

Description:
Attempting to connect to a WiFi AP from a share activity during a new Email Account setup closes all apps.

Pre-Requisite:
Not connected to WiFi/Data

Repro Steps:
1) Update a Flame to 20150717010206
2) Launch Email app and attempt to sign into an account without a data connection
3) Tap Settings icon to get a data connection
4) Select WiFi and attempt to connect to an Access Point


Actual:
Email and Settings App closes

Expected:
User is able to connect to an AP

Environmental Variables:
Device: Flame 2.5 KK 319MB
Build ID: 20150717010206
Gaia: 77bc0d940bde2a5d2d4dfadfcccc6d8d77456d36
Gecko: 8d262d1d0ae5
Gonk: a4f6f31d1fe213ac935ca8ede7d05e47324101a4
Version: 42.0a1 (2.5)
Firmware Version: v18D-1
User Agent: Mozilla/5.0 (Mobile; rv:42.0) Gecko/42.0 Firefox/42.0


Repro frequency: (5/5, 100%)
See attached: logcat

Comment 1

[Peter Bylenga [:PBylenga]]

[Blocking Requested - why for this release]:
Performance Regression, poor UX.


From the logcat I see:
07-17 11:50:32.270  3942  3942 I Gecko   : -*- SettingsManager: Received: inner-window-destroyed for valid innerWindowID=40802189316, cleanup.

Comment 2

[Peter Bylenga [:PBylenga]]

This does NOT occur on Aries KK device with 2.5

Environmental Variables:
Device: Aries 2.5
Build ID: 20150717125848
Gaia: 77bc0d940bde2a5d2d4dfadfcccc6d8d77456d36
Gecko: 15155971639c
Gonk: 2916e2368074b5383c80bf5a0fba3fc83ba310bd
Version: 42.0a1 (2.5)
Firmware Version: D5803_23.1.A.1.28_NCB.ftf
User Agent: Mozilla/5.0 (Mobile; rv:42.0) Gecko/42.0 Firefox/42.0

Comment 3

[Andrew Sutherland [:asuth] (he/him)]

It looks like Gecko is crashing as a result of changing wi-fi settings.  This is more likely to be a gecko/binary blob incompatibility or something otherwise in the wi-fi glue than a problem in the email app or settigns app.  (Or at least, this is definitely not the email app.  We won't automatically retry anything given the state of the email app when you transitioned out.  It's possible the mozbrowser we were using could have retried when it knew it was no longer offline, but then that would be a different platform issue).

Moving to the FxOS:Wifi component for more appropriate triage.

Comment 4

[John Thomas [:Johnt]]

CentralRegression Window

Last Working

Device: Flame 2.5
Environmental Variables
BuildID: 20150622044743
Gaia: 311c4e59936a407e64509f54fecb440d8a78e3c8
Gecko: 20d8b6076d9b
Version: 41.0a1 (2.5)
Environmental Variables:
Device: Flame 2.5

First Broken

Device: Flame 2.5
Environmental Variables
BuildID: 20150624132225
Gaia: eb0d4aefa62b20420d6fa0642515a110daca5d97
Gecko: 7b0df70e27ea
Version: 41.0a1 (2.5)
Firmware Version: v18D-1
User Agent: Mozilla/5.0 (Mobile; rv:41.0) Gecko/41.0 Firefox/41.0


Last Working gaia / First Broken gecko - This issue does NOT occur.
Gaia: 311c4e59936a407e64509f54fecb440d8a78e3c8
Gecko: 7b0df70e27ea

Last Working gecko / First Broken gaia - This issue DOES occur.
Gecko: 20d8b6076d9b
Gaia: eb0d4aefa62b20420d6fa0642515a110daca5d97

Central Pushlog:
https://github.com/mozilla-b2g/gaia/compare/311c4e59936a407e64509f54fecb440d8a78e3c8...eb0d4aefa62b20420d6fa0642515a110daca5d97

This issue is caused by Bug 1144132.

Comment 5

[Andrew Sutherland [:asuth] (he/him)]

Okay, someone needs to file an appropriate spin-off though and dupe this bug to that, because there is nothing the email app can do about any of this.

Comment 6

[Peter Bylenga [:PBylenga]]

Moving to Window Management, not an email bug.

NI on Gabriele to take a look, this looks like it was caused by the commit of bug 1144132

Comment 7

[Gabriele Svelto [:gsvelto]]

This is weird, this seems to be caused by either the Homescreen or Usage app restarting in the background when running the STR and being flagged as foreground tasks even though they're clearly hidden. I smell a window management visibility issue but it could also be a regression caused by my Gecko change. I'll dig further and report back ASAP.

Comment 8

[Gabriele Svelto [:gsvelto]]

OK, this looks like a regression but it's not caused by bug 1144132. It could have been caused by a change in the window management code. In a nutshell what's happening is that when an app is created from the preallocated process it gets a default priority. This is usually the foreground priority when launching an app into the foreground. However what's happening here is that we're launching background apps (e.g. the homescreen) and for some reason they're not re-prioritized so that they're given background priority. So there's two issues: the first is that the homescreen is being launched when we open the settings app. It's unclear why this happens but I suspect it's a regression somewhere in the system app. The second issue is that this new instance of the homescreen is in the background yet gets a foreground priority instead. I'll file a separate bug for the first issue.

Comment 9

[Gabriele Svelto [:gsvelto]]

Another quick update: I mistakenly thought that we were giving the newly created homescreen a foreground priority by accident but in fact we don't. This new process while not being visible is still marked as visible by the system app which prompts the process priority management logic to give it foreground priority.

Comment 10

[Gabriele Svelto [:gsvelto]]

I got the bug dependency wrong, correcting. Anyway now that the underlying bug is fixed this should be fixed too. Peter could you please verify with a build that includes the fix for bug 1186587?

Comment 11

[Peter Bylenga [:PBylenga]]

Still reproduces on today's build

Environmental Variables:
Device: Flame 2.5
Build ID: 20150728030208
Gaia: 14e32276025b0310d3e89027320cf4b2a24cedfb
Gecko: 33dc8a83cfc0
Gonk: 41d3e221039d1c4486fc13ff26793a7a39226423
Version: 42.0a1 (2.5)
Firmware Version: v18D
User Agent: Mozilla/5.0 (Mobile; rv:42.0) Gecko/42.0 Firefox/42.0

Comment 12

[Gabriele Svelto [:gsvelto]]

Thanks for testing, I'll have to dig further into this.

Comment 13

[Mahendra Potharaju [:mahe]]

Gabriele, 

Have you had a chance to look at this? Can you please take a look and set a priority? Its a 2.5 blocker. 


Thanks

Comment 14

[Gabriele Svelto [:gsvelto]]

Not yet, I focused on 2.5+ dialer blockers and didn't realize this was also a blocker. Will look into it today or tomorrow.

Comment 15

[Gabriele Svelto [:gsvelto]]

I've just re-tested this on my Flame and the STR works correctly. I suspect this was an issue caused by the memory usage regressions we encountered in the past few weeks. Bug 1144132 did not cause the issue directly, it just made it visible since it lowered the e-mail app priority below the foreground oom_score_adj threshold. Now that the apps are not consuming too much memory - and the homescreen is not being relaunched - all other apps are properly killed leaving only the e-mail app and settings alive during the configuration.

Peter could you re-test this again too? I'd like to close this as WFM but I'd like to have it confirmed by somebody else with a different build than mine.

Comment 16

[Gabriele Svelto [:gsvelto]]

Re-tested this just in case and still cannot reproduce it, closing as WFM.