Closed Bug 834466 Opened 11 years ago Closed 11 years ago

Homescreen unexpectedly going to "foreground" priority while in the background

Categories

(Firefox OS Graveyard :: Gaia, defect)

Product:
Firefox OS Graveyard
Component:
Gaia
Platform:
ARM
Gonk (Firefox OS)
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(blocking-b2g:tef+, b2g18 fixed, b2g18-v1.0.0 fixed)

Status:
VERIFIED FIXED
Project Flags:
blocking-b2g tef+
Tracking Flags:
Tracking Status
b2g18 --- fixed
b2g18-v1.0.0 --- fixed

People

(Reporter: cjones, Assigned: alive)

References

Details

Attachments

(1 file)

https://github.com/mozilla-b2g/gaia/pull/7849
86 bytes, text/html
timdream
: review+
Details 
STR
 (1) Follow the steps at https://wiki.mozilla.org/B2G/Memory_acceptance_criteria#MW4:_Apps_are_successfully_launched_into_the_foreground_under_memory_pressure

Run "adb shell b2g-ps --oom | grep Homescreen" and you'll see something like

Homescreen           1        166         67         app_531   531   105   70952  18680 ffffffff 4007c330 S /system/b2g/plugin-container

The "1" indicates that the homescreen is in the foreground priority class while it's in the background.
Should this be tef+ since it blocks 834059?
(In reply to Andrew Overholt [:overholt] from comment #1)
> Should this be tef+ since it blocks 834059?

Yes.
blocking-b2g: --- → tef+
Could it be because all the other apps are killed except the homescreen at that point and so it is put into the foreground by Gaia when the Active app is killed?
Flags: needinfo?(jones.chris.g)
Except the browser app is focused when this happens, and the browser app is never killed, because it runs in process.
I tried with bug 834059 applied and could not reproduce this.  After I clicked "bust processes", the homescreen process died and did not come back until I exited the browser app.

This is probably because all tabs get 5s of foreground time with my patch (bug 834059 comment 12).  If so, we haven't really fixed anything here, but have merely covered up the problem.
Does this still block bug 834059?

Who's going to own this?  Justin?  Vivien?  Alive?  cjones?
> Does this still block bug 834059?

If this bug still occurs, then it's possible for the LMK to kill the "wrong" app, which is the summary of bug 834059.  The fix in bug 834059 fixes a specific way that we can get the LMK to kill the wrong app.

So this bug blocks 834059 if we consider that bug to be a metabug of sorts.  If we consider it to be a regular bug, it never blocked bug 834059.

> Who's going to own this?  Justin?  Vivien?  Alive?  cjones?

I'm happy to own this if I can reproduce it.  But I think I've broken cjones's str.  If we can no longer reproduce this, we should probably just close it.
This test was carefully written so that it *didn't* kill the homescreen process, because I couldn't reproduce the problem when it died.  So yeah, we'll need to recheck.

I set this to block 834059 because the homescreen staying foreground could have contributed to the problems launching apps.  If we're good without this fix, then this doesn't block that bug.
Flags: needinfo?(jones.chris.g)
Chris, do you want me to try to reduce or eliminate the 5s of foreground time each process gets when it starts up?  I'm not sure how important this is, nor do I understand exactly what time constraints we're operating under.  (I did the 5s thing because it was the safest and fastest fix I could think of at the time.)
We caught up a bit on IRC, but there are several followups worth investigating

 - is the homescreen still unexpectedly getting fg priority.  We should fix that, but it's a gaia bug.

 - is the original testcase still valid.  It relied on the homescreen staying alive.  If the homescreen is dying now because more of the Browser processes stay fg longer, then we need to fix the test.

 - is the 5s fg too long.  Need good tests to measure that.  A fixed-up "Bust processes" test would be best for that, since all the processes are tiny and launched in as quick a succession as is possible.
(In reply to Chris Jones [:cjones] [:warhammer] from comment #10)
> We caught up a bit on IRC, but there are several followups worth
> investigating
> 
>  - is the homescreen still unexpectedly getting fg priority.  We should fix
> that, but it's a gaia bug.

I am happy to fix this if needed and if fg priority means `setVisible(true)`.
(In reply to Alive Kuo [:alive] from comment #11)
> (In reply to Chris Jones [:cjones] [:warhammer] from comment #10)
> > We caught up a bit on IRC, but there are several followups worth
> > investigating
> > 
> >  - is the homescreen still unexpectedly getting fg priority.  We should fix
> > that, but it's a gaia bug.
> 
> I am happy to fix this if needed and if fg priority means `setVisible(true)`.

That's what means fg priority. But there are also some cases where the equivalent is set by the platform: http://mxr.mozilla.org/mozilla-b2g18/source/dom/browser-element/BrowserElementChild.js#76
(In reply to Vivien Nicolas (:vingtetun) (:21) from comment #12)
> > I am happy to fix this if needed and if fg priority means `setVisible(true)`.
> 
> That's what means fg priority. But there are also some cases where the
> equivalent is set by the platform:
> http://mxr.mozilla.org/mozilla-b2g18/source/dom/browser-element/
> BrowserElementChild.js#76

In case this is a gaia bug.
My *dry running* guess to STR in https://wiki.mozilla.org/B2G/Memory_acceptance_criteria#MW4:_Apps_are_successfully_launched_into_the_foreground_under_memory_pressure

Because the call screen drops, the visibility of the memory buster app(browser) is going to be false in 5 sec.
So it SOONLY be killed because it is not foreground (call screen is on top).
Window manager sees the app is terminated so it just brings the background app which is homescreen to foreground ....regardless to the state of attention screen.
https://github.com/mozilla-b2g/gaia/blob/master/apps/system/js/window_manager.js#L1844
That sounds like a winner to me!
(In reply to Justin Lebar [:jlebar] from comment #14)
> That sounds like a winner to me!
\O/

So sounds like I win one more tef+ bug?

I hate that I am right that we really have trouble on maintaining the fg priority of 1) apps, 2) multiple attention screen, 3) multiple inline-activities, and any other similar browerAPI iframes. :/

I don't know if this one is need to be treated as a blocking bug per comment 10, but the fix here -- for short term -- should be easy.
Assignee: nobody → alive
WIP patch v1:
Check attention screen status before bringing homescreen to foreground by appterminated.

Notice:
Don't have a phone for test now so I will test this patch and set r? tomorrow.
OS: Linux → Gonk (Firefox OS)
Hardware: x86_64 → ARM
Updated WIP v2.

I am not if the STR is still valid, because I cannot make a call from other phone when the memory is busted even w/o the patch.
Comment on attachment 707613 [details]
https://github.com/mozilla-b2g/gaia/pull/7849

There are another bug I see:
When a web page in browser app is calling a view activity,
the homescreen app would be brought to fg due to setDisplayedApp by anyway setVisible(true) to homescreen at the beginning.
Attachment #707613 - Flags: review?(timdream)
Marking status-b2g18 and status-b2g18-v1.0.0 as affected, please update the status to fixed once this is verified landed on v1-train/mozilla-b2g18 and v1.0.0/mozilla-b2g18_v_1_0_0
status-b2g18: --- → affected
status-b2g18-v1.0.0: --- → affected
Attachment #707613 - Flags: review?(timdream) → review+
Unagi Build ID: 20130313070202
Gecko: http://hg.mozilla.org/releases/mozilla-b2g18_v1_0_1/rev/e74dafa6b2d9
Gaia: b34e726147f8e671ad8c538b50900ccfbffcb084
Kernel: Dec 5th

The "1" indicates that the homescreen is in the foreground priority class while it's in the background. Does not reproduce.
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: