1186587 - The homescreen is relaunched after having been killed even though it's not been made visible

Status: RESOLVED WORKSFORME

(Firefox OS Graveyard :: Gaia::System, defect)

Description

[Gabriele Svelto [:gsvelto]]

+++ This bug was initially created as a clone of Bug #1184993 +++

STR:
1. Launch the e-mail app
2. Kill the homescreen, the following command will do the trick: adb shell kill $(adb shell b2g-info | grep Homescreen | cut -b16-21)
3. Pull down the system tray and launch the settings app
4. Wait a few seconds then run adb shell b2g-info

Excpected result:
The homescreen is not present among the running processes

Actual result:
The homescreen is present among the running processes, it has been relaunched at some stage

This is rather bad as it limits the maximum amount of memory available on low-end devices as the homescreen will kill other background apps in order to start. Since we don't know in which scenario it's being relaunched we might also risk running into a launch-get-LMK'd-then-launch-again-and-start-over cycle.

Comment 1

[Gabriele Svelto [:gsvelto]]

Etienne, I smell a regression here and a pretty bad one too, do you know who's dealing with the mechanisms related to the homescreen in the system app now?

Comment 2

[Gabriele Svelto [:gsvelto]]

I've got an additional data point here. The newly created homescreen is marked as visible by the system app even though it's clearly not.

Comment 3

[Gregor Wagner [:gwagner]]

Thats expected behavior. We always try to re-start the homescreen when it gets killed afaik.

Comment 4

[Gabriele Svelto [:gsvelto]]

Are you sure that's the case? In the general case I thought we didn't to prevent loops where the homescreen gets launched, killed, launched again and so on. I seem to remember that when killed we relaunched it only when going back to it. That being said in this bug we're not relaunching it automatically, it's being relaunched right after starting the settings app. Also it's marked as visible though it's clearly not which is even more puzzling.

Comment 5

[Gregor Wagner [:gwagner]]

Kevin probably remembers the details here.

Comment 6

[Kevin Grandon :kgrandon]

I don't unfortunately know the details here, Alive probably would. Relaunching sounds like it might not be ideal if it's not shown to the user. The fact that we show it as visible is also pretty bad. Sounds like something that we should probably fix.

Comment 7

[Gabriele Svelto [:gsvelto]]

From what I can tell this is new behavior, I never experienced it in the past. I'll try to get a regression window in case it's something that's been introduced recently.

Comment 8

[Gabriele Svelto [:gsvelto]]

OK, I went back quite a few months and this doesn't seem to be a regression. While going back in gaia versions past the one where we shortened animations: going past that one I noticed one thing I hadn't noticed before. Once you're in the e-mail app, launching the settings app causes the homescreen wallpaper to appear very briefly before the settings app slides in from the right. I wonder if there's  a glitch or a race somewhere in the application startup path that causes the homescreen to be relaunched. If there is then it's also probably responsible for not updating its visibility correctly.

Comment 9

[GitHub Autolander Bot]

Attachment: [gaia] etiennesegonzac:bug-1186587 > mozilla-b2g:master

Comment 10

[Gabriele Svelto [:gsvelto]]

OK, I've figured out what the issue is. When launching a new app we trigger the app switching code which tries to fade out the homescreen here, as if we were launching from the homescreen:

https://github.com/mozilla-b2g/gaia/blob/7cfe9eb9ade41043dea02d350680735b815d9c5a/apps/system/js/homescreen_window_manager.js#L30

This causes the homescreen to be fetched, in theory the getHomescreen() function should ensure that the homescreen is running only when passed a boolean parameter set to true, but in fact it always launches the homescreen, see here:

https://github.com/mozilla-b2g/gaia/blob/7cfe9eb9ade41043dea02d350680735b815d9c5a/apps/system/js/homescreen_window_manager.js#L58

I'll prepare a quick fix for this, because this issue in and by itself is rather trivial. I'm somewhat worried about the potential fallout since this method was supposed to launch the homescreen conditionally and in fact it's launching it unconditionally so I'll have to keep my eyes peeled for regressions.

Clearing the remaining NI for the moment.

Comment 11

[Gabriele Svelto [:gsvelto]]

Duh, it looks like Etienne was faster than me :-p

Comment 12

[Kevin Grandon :kgrandon]

Comment on attachment 8637784 [details] [review]
[gaia] etiennesegonzac:bug-1186587 > mozilla-b2g:master

Looks good to me, thank you for the quick fix!

Comment 13

[Kevin Grandon :kgrandon]

In master: https://github.com/mozilla-b2g/gaia/commit/db299103dd17a873cba4ff88e62ec173bf80fe62

Comment 14

[GitHub Autolander Bot]

Attachment: [gaia] KevinGrandon:bug_1188459_revert_smoketest_blocker_2 > mozilla-b2g:master

Comment 15

[Kevin Grandon :kgrandon]

Sorry, I was requested to revert this due to causing a smoketest blocker, bug 1188459. Etienne - please take a look if you can. 

https://github.com/mozilla-b2g/gaia/commit/a317a3edc00eea564d39bd89d032a76546477cd7

Comment 16

[Etienne Segonzac (:etienne)]

I thought maybe we were hitting a code path where the |getHomescreen| call was wrong (ie. not ensuring where it should). But can't find any :/

Gabriele, any idea?

Comment 17

[Gabriele Svelto [:gsvelto]]

There's nothing obvious besides what we saw in bug 1187819. I haven't had time to study bug 1188459 in detail and I'll be on PTO for two weeks starting tomorrow so I doubt I'll be able to get back to this soon :-(