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

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

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

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.

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.

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.

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

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.

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.

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.

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?

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

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

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

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.

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.

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