1055299 - Multiple foreground apps cause LMK to kill actual foreground app

Status: RESOLVED FIXED

(Firefox OS Graveyard :: Gaia::System::Window Mgmt, defect, P1)

Description

[Tapas[:tkundu on #b2g/gaia/memshrink/gfx] (always NI me)]

Attachment: full logs

We found following logs during multimedia stability test in  v2.0 :

08-18 13:27:04.026   254   254 I cat     : <6>[19088.499642] send sigkill to 29289 (Video), adj 134, size 1928

But video app was in forground when it is killed by LMK.

here is the b2g-info logs which shows multiple apps are becoming forground app:

[H[JEvery 2s: b2g-info                                          2014-08-18 13:27:03

                           |     megabytes     |
           NAME   PID PPID CPU(s) NICE  USS  PSS  RSS SWAP VSIZE OOM_ADJ USER     
            b2g  5208    1 2502.3    0 10.8 11.7 13.6 52.8 278.2       0 root     
         (Nuwa)  5367 5208   62.1    0  0.0  0.1  0.6  7.8  53.8       0 root     
     Homescreen 17791 5367   14.0    1  2.1  2.6  4.3 15.2  87.0       2 u0_a17791
(Preallocated a 29287 5367    1.0   18  0.6  0.8  1.9 10.4  60.9       1 u0_a29287
          Video 29289 5208    4.2    1  4.0  4.5  6.0 12.1 100.5       2 u0_a29289
     Callscreen 29303 5367    1.7    1  3.4  4.3  6.4 10.5  66.2       2 u0_a29303

System memory info:

            Total 167.6 MB
        SwapTotal 192.0 MB
     Used - cache 151.8 MB
  B2G procs (PSS)  24.0 MB
    Non-B2G procs 127.7 MB
     Free + cache  15.9 MB
             Free   6.6 MB
            Cache   9.3 MB
         SwapFree  72.4 MB

Low-memory killer parameters:

  notify_trigger 9216 KB

  oom_adj min_free
        0  4096 KB
       58  5120 KB
      117  6144 KB
      352  7168 KB
      470  8192 KB
      588 10240 KB


Please note that we have fix from bug 1047645 in our build .

I am trying to capture a memory report from affected device soon :)

Comment 1

[Tapas[:tkundu on #b2g/gaia/memshrink/gfx] (always NI me)]

[Blocking Requested - why for this release]:

Comment 2

[Tapas[:tkundu on #b2g/gaia/memshrink/gfx] (always NI me)]

My guess it is caused by gaia app transition controller. 

@kyle: I am trying to capture memory report for you to quickly checking it :)

Comment 3

[Tapas[:tkundu on #b2g/gaia/memshrink/gfx] (always NI me)]

@kevin: i am enabling logs by following https://bugzilla.mozilla.org/show_bug.cgi?id=1050751#c55 . Please provide us a patch if you need more logs :)

Comment 4

[Kevin Grandon :kgrandon]

Tapas - can you clarify what user impact this has on the end user? Does it mean that the active app they are using will be killed? Does it only happen after opening the app, or can it happen at any time?

(In reply to Tapas Kumar Kundu from comment #2)
> My guess it is caused by gaia app transition controller. 

This could be the case if we did not set the proper foreground status on the app, but seems unlikely to me. I am trying to look into the logs right now, and it seems we press the home button, then the video app gets killed.

08-18 13:26:58.426  5208  5208 E GeckoConsole: Content JS LOG at app://system.gaiamobile.org/js/app_window_manager.js:663 in awm_debug: [AppWindowManager][1408393381.904]handling home
 ... snip ~6 seconds later ...
08-18 13:27:04.026   254   254 I cat     : <6>[19088.499642] send sigkill to 29289 (Video), adj 134, size 1928

(In reply to Tapas Kumar Kundu from comment #0)
> I am trying to capture a memory report from affected device soon :)

Will sit down with Kyle once we have the memory report - I think we need this to move forward. Clearing ni? for now.

Comment 5

[Tapas[:tkundu on #b2g/gaia/memshrink/gfx] (always NI me)]

(In reply to Kevin Grandon :kgrandon from comment #4)
> Tapas - can you clarify what user impact this has on the end user? Does it
> mean that the active app they are using will be killed? Does it only happen
> after opening the app, or can it happen at any time?
> 

Yes it is happening if user is using video app actively . 

>>  can it happen at any time?
I am not sure. In our case, we are running stability test for 2-3 hours to see it.

Comment 6

[Kevin Grandon :kgrandon]

(In reply to Tapas Kumar Kundu from comment #5)
> (In reply to Kevin Grandon :kgrandon from comment #4)
> > Tapas - can you clarify what user impact this has on the end user? Does it
> > mean that the active app they are using will be killed? Does it only happen
> > after opening the app, or can it happen at any time?
> > 
> 
> Yes it is happening if user is using video app actively . 

Ok, but can you please clarify what happens to the end user. Are they opening the video app, then it is killed by LMK while they are watching a video? Is it running in the background when they go to open it again?

A video of what happens here would be very useful.

Comment 7

[Kyle Huey (Exited; not receiving bugmail, old account, do not use)]

The log appears to show that the home button was pressed and we moved the Homescreen to the foreground.  If that happened, killing the Video app to make room for the Homescreen would be expected behavior.

Comment 8

[Gabriele Svelto [:gsvelto] (PTO)]

Was the callscreen reduced in statusbar mode when the video app was open? That's the only way they could have been both in the foreground. There is a long stretch where both the Video app, Callscreen and Homescreen appear to be in the foreground and that shouldn't be possible. It would be really helpful if we knew the exact sequence of events that triggered this behavior.

One possibility is that we have a bug in the window manager that's not reporting visibility correctly for the open applications. This would confuse the process priority manager as the only way for an app to be considered in the foreground is that it must be visible. So looking at that log, at that point in time where the three apps had an OOM_ADJ of 2, TabParent::IsVisible() [1] was returning true for the three of them.

[1] http://hg.mozilla.org/mozilla-central/file/111a1da2a95d/dom/ipc/TabParent.cpp#l269

Comment 9

[Gabriele Svelto [:gsvelto] (PTO)]

Now that I think of it there is one scenario in which we can have multiple apps which are considered visible even when they aren't and that's when using activities, see bug 892371 and bug 846850, but I don't think that's the case here.

Comment 10

[Tapas[:tkundu on #b2g/gaia/memshrink/gfx] (always NI me)]

(In reply to Kyle Huey [:khuey] ([e-mail]) from comment #7)
> The log appears to show that the home button was pressed and we moved the
> Homescreen to the foreground.  If that happened, killing the Video app to
> make room for the Homescreen would be expected behavior.

I partially agree for this. 

I have following questions :

1) If we run |while true; do adb shell b2g-info; sleep 1 ; done| in one shell and open any app (lets assume it is video app) manually and close it then we can see both homescreen and video app is getting OOM_ADJ=2 (foreground) momentarily . It happens all the time and my question is whether it is expected behaviour or not . 

2) In Comment 0, we are seeing 3 app has became foreground which is very strange to me. Can you please dig into that . I don't memory report for that .I am trying to collect it in next run.

3) I got a new memory report when video app is getting killed if we try to close it manually after playback of video finishes. I attached screenshot which is taken from affected device after video app is killed. You can see that video app iframe is still visible although video app process does not exist. You can also see dom tree nodes from affected device in this case. Logs for this case is in :

https://drive.google.com/file/d/0B1cSMS8_GuAELU5ic3ZaaEFWbjA/edit?usp=sharing


But we have not seen >=3 foreground apps in this run like comment 0. I am still trying to reproduce that case (Comment 0).

Comment 11

[Tapas[:tkundu on #b2g/gaia/memshrink/gfx] (always NI me)]

(In reply to Kevin Grandon :kgrandon from comment #6)
> Ok, but can you please clarify what happens to the end user. Are they
> opening the video app, then it is killed by LMK while they are watching a
> video? Is it running in the background when they go to open it again?
> 

End user is opening video app, playing video and closing video app. LMK kills video app just before user presses home button for long time . You can see screenshot in Comment 10. 

Impact is that video app process is killed by LMK but video app iframe is still visible. Logs are in Comment 10.

> A video of what happens here would be very useful.

we don't have videos but we have screenshot from one of the affected device in Comment 10


Please note that logs in Comment 10 does not show 3 forground apps but logs in Comment 0 is showing 3 foreground app for same test steps. I am still trying to reproduce Comment 0.

Meanwhile , could you please answer my questions in Comment 10 ? . I also want to know why video app Iframe is not cleared automatically when LMK kills video app.

Comment 12

[Kevin Grandon :kgrandon]

Ok, so we are performing a LMK of the app as we go into task manager, that clears things up a bit. I'm still unsure of the impact to the end user though - can we clarify more? 

1 - What happens when the user taps on the active card in the task manager?
2 - What happens when the user presses the 'X' in the task manager?
3 - What happens when the user presses the home button?

It seems like we should try to fix the multiple foreground process issue for sure, if there is a problem there.

Comment 13

[Preeti Raghunath(:Preeti)]

Michael

Can we please help understand why this would be a blocker?

Comment 14

[Inder]

Preeti -- this issue showed up in our multimedia related stability testing recently. I had communicated it to :bajaj yesterday.

Comment 15

[David Flanagan [:djf]]

We were seeing multiple foreground apps in the logs for bug 1047645 as well.  The context here is an automated stress test and (presumably) intense zmem thrashing. Ordinary actions like switching from one app to another can take 10 times longer than they normally do when we are at the limit of available memory. It is just a recipe for race conditions. I'm not actually worried that ordinary users will encounter bugs like this, but it does seem like we should always treat race conditions seriously and get to the bottom of them even if there isn't much actual end-user impact.

The first question I'd have is this. What happens in the system app if the user presses the home button and then launches a new app from the homescreen before the app that used to be the foreground app has completely transitioned to the background.  We're seeing in bug 1051172 that it can take many seconds before the Camera app receives its visibilitychange event and actually goes to the background, and there would be plenty of time in that case for the user to launch a new app while the old app is still technically in the foreground.  That seems like the kind of situation that someone who understands the window management code in the system app ought to work through to see if it could cause problems.

But it looks like bug 1047645 already included window management fixes, so maybe there is a race condition further down the stack.  When the system app makes a frame foreground or background, somehow that has to be passed down the stack to gecko and then to the linux kernel when things like process priorities and the OOM_ADJ value are set.  I know nothing at all about that code, but presumably it involves multiple processes subject to virtual memory thrashing issues, so it also seems like we could be very racy at the low levels. Could process priority transitions happen out of order?  

Is the LMK process affected by thrashing? Could there be apps that have been selected to be killed by the LMK that aren't getting killed promptly enough because of thrashing? How does the system app find out when an app is killed because of low memory? Could it be that the system app thinks that apps have been killed when they haven't actually been killed?

At this point I've gone beyond informed speculation and am just starting to guess, so I'll stop here.

Comment 16

[Kyle Huey (Exited; not receiving bugmail, old account, do not use)]

(In reply to Tapas Kumar Kundu from comment #10)
> I have following questions :
> 
> 1) If we run |while true; do adb shell b2g-info; sleep 1 ; done| in one
> shell and open any app (lets assume it is video app) manually and close it
> then we can see both homescreen and video app is getting OOM_ADJ=2
> (foreground) momentarily . It happens all the time and my question is
> whether it is expected behaviour or not . 

Yes, this is expected.  Priority adjustment is done on a timer.  The timing values are controlled by preferences set at http://hg.mozilla.org/mozilla-central/annotate/4d94eeca89f3/b2g/app/b2g.js#l672.  The timing values are designed to make it so that processes are not killed unnecessarily during transitions between apps.

> 2) In Comment 0, we are seeing 3 app has became foreground which is very
> strange to me. Can you please dig into that . I don't memory report for that
> .I am trying to collect it in next run.

That does seem unusual.  It's not entirely clear what's going on here.  From the logcat:

08-18 13:27:11.396  5208  5208 I Gecko:ProcessPriorityManager: [Callscreen, child-id=643, pid=29303] Scheduling reset timer to fire in 1000ms.
08-18 13:27:11.406  5208  5219 I Gecko   : [Parent 5208] WARNING: waitpid failed pid:29303 errno:10: file ../../../../../../../../gecko/ipc/chromium/src/base/process_util_posix.cc, line 261
08-18 13:27:11.416  5208  5208 I Gecko:ProcessPriorityManager: [Callscreen, child-id=643, pid=-1] Got wake lock changed event. Now mHoldsCPUWakeLock=0, mHoldsHighPriorityWakeLock=0
08-18 13:27:11.416  5208  5208 I Gecko:ProcessPriorityManager: [Callscreen, child-id=643, pid=-1] ScheduleResetPriority bailing; the timer is already running.

The waitpid call that fails is in http://mxr.mozilla.org/mozilla-central/source/ipc/chromium/src/base/process_util_posix.cc#247, at which point it appears that Gecko becomes convinced the process has died, as noted by the following instances of "pid=-1".  errno is SIGCHILD, which is actually totally sensible since app processes are children of Nuwa and grandchildren of the b2g process.  I guess I'll file a bug on that.

> 3) I got a new memory report when video app is getting killed if we try to
> close it manually after playback of video finishes. I attached screenshot
> which is taken from affected device after video app is killed. You can see
> that video app iframe is still visible although video app process does not
> exist. You can also see dom tree nodes from affected device in this case.

If the bug here is just that an app that has been killed is still in the task manager, I don't think that's a blocker, especially if the app is not "stuck" in the task manager.  The questions from comment 12 are relevant here.

Comment 17

[Kyle Huey (Exited; not receiving bugmail, old account, do not use)]

I filed bug 1055731.

Comment 18

[Tapas[:tkundu on #b2g/gaia/memshrink/gfx] (always NI me)]

(In reply to Kevin Grandon :kgrandon from comment #12)
> Ok, so we are performing a LMK of the app as we go into task manager, that
> clears things up a bit. I'm still unsure of the impact to the end user
> though - can we clarify more? 
> 
> 1 - What happens when the user taps on the active card in the task manager?
> 2 - What happens when the user presses the 'X' in the task manager?
> 3 - What happens when the user presses the home button?
> 

Unfortunately, I don't have an affected device ready where I can try these steps. I will try these once issue is reproduced again and I will update asap today.

> It seems like we should try to fix the multiple foreground process issue for
> sure, if there is a problem there.

Yes, 3 foreground apps in comment 0 definitely points us to some RACE somewhere in app transition.

Comment 19

[Tapas[:tkundu on #b2g/gaia/memshrink/gfx] (always NI me)]

(In reply to Kyle Huey [:khuey] ([e-mail]) from comment #16)
> (In reply to Tapas Kumar Kundu from comment #10)
> > I have following questions :
> > 
> > 1) If we run |while true; do adb shell b2g-info; sleep 1 ; done| in one
> > shell and open any app (lets assume it is video app) manually and close it
> > then we can see both homescreen and video app is getting OOM_ADJ=2
> > (foreground) momentarily . It happens all the time and my question is
> > whether it is expected behaviour or not . 
> 
> Yes, this is expected.

Thanks for clarification. 

> 
> > 2) In Comment 0, we are seeing 3 app has became foreground which is very
> > strange to me. Can you please dig into that . I don't memory report for that
> > .I am trying to collect it in next run.
> 
> That does seem unusual.  It's not entirely clear what's going on here.  From
> the logcat:
> 
> 08-18 13:27:11.396  5208  5208 I Gecko:ProcessPriorityManager: [Callscreen,
> child-id=643, pid=29303] Scheduling reset timer to fire in 1000ms.
> 08-18 13:27:11.406  5208  5219 I Gecko   : [Parent 5208] WARNING: waitpid
> failed pid:29303 errno:10: file
> ../../../../../../../../gecko/ipc/chromium/src/base/process_util_posix.cc,
> line 261
> 08-18 13:27:11.416  5208  5208 I Gecko:ProcessPriorityManager: [Callscreen,
> child-id=643, pid=-1] Got wake lock changed event. Now mHoldsCPUWakeLock=0,
> mHoldsHighPriorityWakeLock=0
> 08-18 13:27:11.416  5208  5208 I Gecko:ProcessPriorityManager: [Callscreen,
> child-id=643, pid=-1] ScheduleResetPriority bailing; the timer is already
> running.
> 
> The waitpid call that fails is in
> http://mxr.mozilla.org/mozilla-central/source/ipc/chromium/src/base/
> process_util_posix.cc#247, at which point it appears that Gecko becomes
> convinced the process has died, as noted by the following instances of
> "pid=-1".  errno is SIGCHILD, which is actually totally sensible since app
> processes are children of Nuwa and grandchildren of the b2g process.  I
> guess I'll file a bug on that.
> 

Nice find. Thanks.  We are waiting to get a fix from bug 1055731

Comment 20

[Kyle Huey (Exited; not receiving bugmail, old account, do not use)]

(In reply to Tapas Kumar Kundu from comment #19)
> Nice find. Thanks.  We are waiting to get a fix from bug 1055731

I don't think a fix for bug 1055731 is possible in the 2.0 timeframe.

Comment 21

[Eric Rahm [:erahm]]

Removing MemShrink, sounds like this is more of a LMK killing the wrong app issue.

Comment 22

[Gabriele Svelto [:gsvelto] (PTO)]

(In reply to David Flanagan [:djf] from comment #15)
> We're seeing in bug 1051172 that it can
> take many seconds before the Camera app receives its visibilitychange event
> and actually goes to the background, and there would be plenty of time in
> that case for the user to launch a new app while the old app is still
> technically in the foreground.

I think that's worth further investigation. We rely on the visibilitychange event to adjust the process priorities assuming that happens immediately. If the visibilitychange event is delayed it can unnecessarily slow down the process priority adjustments which in turn will affect app startup time and might risk having the wrong app killed by the LMK when under memory pressure.

Comment 23

[Dietrich Ayala (:dietrich)]

Triage discussed and concluded blocking+ for 2.0 because this appears to be a regression. We need to know what change in 2.0 development timeframe caused this, and how to test to ensure issues like this are caught immediately. If not a regression, please renominate and we can continue the discussion with downstream partners.

Comment 24

[Kyle Huey (Exited; not receiving bugmail, old account, do not use)]

It's still not clear what this bug is actually about ...

Comment 25

[Kevin Grandon :kgrandon]

Please see comment 18. I don't think we can block on this until we know what the actual user impact is.

Comment 26

[Mike Habicher [:mikeh] (high bugzilla latency)]

Moving this from the Video app since it sounds like this is a system-level problem. Kevin, can you bump this to a different component if something else is more correct?

Comment 27

[Kevin Grandon :kgrandon]

Sounds like the right component until we have more information.

Comment 28

[bhavana bajaj [:bajaj]]

We are waiting for CAF to see if they are reproducing this again and can have logs without which there is nothing much to do here atm.

Comment 29

[(inactive after 6/18) Alive Kuo [:alive]]

I had some trick to maintain only one opened app in https://bugzilla.mozilla.org/show_bug.cgi?id=1056216.
Not sure if this is the dupe and still waiting Tapus response.

Comment 30

[Tapas[:tkundu on #b2g/gaia/memshrink/gfx] (always NI me)]

(In reply to Alive Kuo [:alive][NEEDINFO!] from comment #29)
> I had some trick to maintain only one opened app in
> https://bugzilla.mozilla.org/show_bug.cgi?id=1056216.
> Not sure if this is the dupe and still waiting Tapus response.

We tested with your fix and we can still see multiple foreground apps . 

STR is:
1) Reboot & load 256MB image and touch 3 app icons phone,messages,contacts quickly.
   You will see all 3 apps are opening 
2) Press homekey and device has became slow now. it takes time to response if we press home key.
3) Now if we touch any icon then it takes time 1-2 secs to launch apps.
4) Now if you try touch 7-8 app icons then device is extremely slow and reason is multiple foreground apps . 

I know if you may still find it difficult to reproduce with this STR. 

I want to know why gecko assigns multiple process as foreground priority when user touches multiple app icons. If we run multiple app as forground then LMK won't kill it and device will become very slow quickly. If we debug from this direction then we can conclude it faster. 

If we compare FFOS 2.0 with FFOS v1.3 build then we will see a big difference between them for THIS STR.
FFOS v1.3 seems to be very fast to maintain only one foreground app even if we launch multiple apps.

Comment 31

[Tapas[:tkundu on #b2g/gaia/memshrink/gfx] (always NI me)]

I suspect that this is the root cause of bug 1056216. We are using same STR for that too.

Comment 32

[Kevin Grandon :kgrandon]

Tapas - thanks for the awesome STR. Is it possible for you to grab a memory report with the phone in this state? Thanks!

Comment 33

[Ting-Yu Chou [:ting] (away)]

(In reply to Tapas  (always NI me) from comment #30)
> 4) Now if you try touch 7-8 app icons then device is extremely slow and
> reason is multiple foreground apps . 

Just my 2 cents, is it a valid test/use case to launch many apps simultaneously, does user do/need that?

Comment 34

[(inactive after 6/18) Alive Kuo [:alive]]

(In reply to Tapas  (always NI me) from comment #30)
> (In reply to Alive Kuo [:alive][NEEDINFO!] from comment #29)
> > I had some trick to maintain only one opened app in
> > https://bugzilla.mozilla.org/show_bug.cgi?id=1056216.
> > Not sure if this is the dupe and still waiting Tapus response.
> 
> We tested with your fix and we can still see multiple foreground apps . 
> 
> STR is:
> 1) Reboot & load 256MB image and touch 3 app icons phone,messages,contacts
> quickly.
>    You will see all 3 apps are opening 
> 2) Press homekey and device has became slow now. it takes time to response
> if we press home key.
> 3) Now if we touch any icon then it takes time 1-2 secs to launch apps.
> 4) Now if you try touch 7-8 app icons then device is extremely slow and
> reason is multiple foreground apps . 
> 
> I know if you may still find it difficult to reproduce with this STR. 
> 
> I want to know why gecko assigns multiple process as foreground priority
> when user touches multiple app icons. If we run multiple app as forground
> then LMK won't kill it and device will become very slow quickly. If we debug
> from this direction then we can conclude it faster. 
> 
> If we compare FFOS 2.0 with FFOS v1.3 build then we will see a big
> difference between them for THIS STR.
> FFOS v1.3 seems to be very fast to maintain only one foreground app even if
> we launch multiple apps.

* It's not gecko to assign the foreground app but gaia. But actually we won't assign more then two foreground apps.
* I have the same question as comment 33, how do you launch 7-8 apps one time?
* It seems to me: LMK doesn't work before the phone become unavailable, from your statements:
  "Press homekey and device has became slow now. it takes time to response"
  "then device is extremely slow"
  So if gaia has difficulty to send some apps to background I won't be surprised.

Comment 35

[Tapas[:tkundu on #b2g/gaia/memshrink/gfx] (always NI me)]

(In reply to Ting-Yu Chou [:ting] from comment #33)
> (In reply to Tapas  (always NI me) from comment #30)
> > 4) Now if you try touch 7-8 app icons then device is extremely slow and
> > reason is multiple foreground apps . 
> 
> Just my 2 cents, is it a valid test/use case to launch many apps
> simultaneously, does user do/need that?

We don't see this issue in FFOS v1.3 and it makes phone very slow. End users will find phone slow. IMO, we must solve this

Comment 36

[Tapas[:tkundu on #b2g/gaia/memshrink/gfx] (always NI me)]

(In reply to Alive Kuo [:alive][NEEDINFO!] from comment #34)
> (In reply to Tapas  (always NI me) from comment #30)
> * It's not gecko to assign the foreground app but gaia. But actually we
> won't assign more then two foreground apps.

Could you please provide me link to gaia code which does this ? I am just curious to learn more about code which is handling this :)

Comment 37

[(inactive after 6/18) Alive Kuo [:alive]]

(In reply to Tapas  (always NI me) from comment #36)
> (In reply to Alive Kuo [:alive][NEEDINFO!] from comment #34)
> > (In reply to Tapas  (always NI me) from comment #30)
> > * It's not gecko to assign the foreground app but gaia. But actually we
> > won't assign more then two foreground apps.
> 
> Could you please provide me link to gaia code which does this ? I am just
> curious to learn more about code which is handling this :)

https://github.com/mozilla-b2g/gaia/blob/v2.0/apps/system/js/app_transition_controller.js#L211

Comment 38

[howie [:howie]]

Hi Tapas, could you also give answer to Comment 34 as well as https://bugzilla.mozilla.org/show_bug.cgi?id=1056216#c28 ?

How did you launch 7-8 apps at one time? Did those events come from actual human touching the screen? Or it's programmatically triggered?

Thanks.

Comment 39

[Tapas[:tkundu on #b2g/gaia/memshrink/gfx] (always NI me)]

(In reply to howie [:howie] from comment #38)
> Hi Tapas, could you also give answer to Comment 34 as well as
> https://bugzilla.mozilla.org/show_bug.cgi?id=1056216#c28 ?
> 
> How did you launch 7-8 apps at one time? Did those events come from actual
> human touching the screen? Or it's programmatically triggered?
> 
> Thanks.

We are not using any automated test to reproduce this issue . We are using only manual test. So all events are coming from human touching screen.

Comment 40

[howie [:howie]]

Hi Tapas, maybe a STR video can really help here? qawanted see if QA can reproduce this as Comment 30 mentioned. Also, I suppose Comment 30 use Flame, same as bug 1056216 comment 37, but is Flame 256MB the proper testing condition? I thought we should test at least on 319MB and more?

Comment 41

[bhavana bajaj [:bajaj]]

(In reply to howie [:howie] from comment #40)
> Hi Tapas, maybe a STR video can really help here? qawanted see if QA can
> reproduce this as Comment 30 mentioned. Also, I suppose Comment 30 use
> Flame, same as bug 1056216 comment 37, but is Flame 256MB the proper testing
> condition? I thought we should test at least on 319MB and more?

hi howie,

We may not be able to repro this as this is QRD specific, I tried asking QA but no luck. If you can reach out to someone form Taipei QA and who can try this on a Flame with KK that could be possible.

Yes, QRD 256MB equivalents to 319MB on Flame(atleast that was evaluated to being closest we could get given how the RAm/memory is configured.)

Comment 42

[Kai-Chih Hu [:khu]]

(In reply to bhavana bajaj [:bajaj] from comment #41)
> (In reply to howie [:howie] from comment #40)
> > Hi Tapas, maybe a STR video can really help here? qawanted see if QA can
> > reproduce this as Comment 30 mentioned. Also, I suppose Comment 30 use
> > Flame, same as bug 1056216 comment 37, but is Flame 256MB the proper testing
> > condition? I thought we should test at least on 319MB and more?
> 
> hi howie,
> 
> We may not be able to repro this as this is QRD specific, I tried asking QA
> but no luck. If you can reach out to someone form Taipei QA and who can try
> this on a Flame with KK that could be possible.

Brian, can you help? Thanks.

Comment 43

[Brian Huang [:brianhuang][:brhuang]]

Mike, pls help to use comment 30 to repro this issue.

Comment 44

[Kai-Chih Hu [:khu]]

Alive, since you may have solid background about this, do you think you can be the owner for this bug? Thank you!

Comment 45

[Tapas[:tkundu on #b2g/gaia/memshrink/gfx] (always NI me)]

I am discussing with Alive in #gaia to make sure that he can reproduce it with his 256MB flame :)

Comment 46

[Mike Lien[:mlien]]

Follow comment 30 STR to reproduce with 319 MB Flame KK + 2.0 gaia/gecko
It can launch 3 apps quickly but no performance problem after 3 apps are launched
Only when launch more than 9 apps, performance will get worse

Gaia      d889984833025f208cfd3f3c2c37c87940a529dc
Gecko     6329352ca531b977979451e77e5862af485388b2
BuildID   20140826030000
Version   32.0

Comment 47

[(inactive after 6/18) Alive Kuo [:alive]]

(In reply to Mike Lien[:mlien] from comment #46)
> Follow comment 30 STR to reproduce with 319 MB Flame KK + 2.0 gaia/gecko
> It can launch 3 apps quickly but no performance problem after 3 apps are
> launched
> Only when launch more than 9 apps, performance will get worse
> 
> Gaia      d889984833025f208cfd3f3c2c37c87940a529dc
> Gecko     6329352ca531b977979451e77e5862af485388b2
> BuildID   20140826030000
> Version   32.0

What do you mean by worse? Could you tell me the |adb shell b2g-info| output?

Eventually the background apps will be killed normally and you will not see 9 apps at the same time.

Comment 48

[(inactive after 6/18) Alive Kuo [:alive]]

(In reply to Tapas[:tkundu on #b2g/gaia/memshrink/gfx] (always NI me) from comment #45)
> I am discussing with Alive in #gaia to make sure that he can reproduce it
> with his 256MB flame :)

Unfortunately my oom killer works fine. Even the STR is "quick click icons in homescreen"(which is not an usual user action..). In the long run all apps are killed normally.

I recommend Tapas to provide repro video and logs. Let's wait and see.

Comment 49

[Mike Lien[:mlien]]

Actually there have 12 background apps in the meantime on my environment
The worse performance means launch app and back to homescreen will consume more than 1~2 seconds

                           |     megabytes     |
           NAME   PID PPID CPU(s) NICE  USS  PSS  RSS VSIZE OOM_ADJ USER     
            b2g   205    1  185.1    0 42.8 44.4 49.7 242.8       0 root     
         (Nuwa)   882  205    4.3    0  0.0  0.0  0.6  53.7       0 root     
     Homescreen   932  882   71.5   18  9.1 10.9 16.8  74.1       8 u0_a932  
          Video  3037  882    2.4   18  0.2  0.3  1.1  62.9      13 u0_a3037 
          Music  3236  882    2.4   18  0.2  0.3  1.1  65.9      13 u0_a3236 
        Gallery  3237  205    2.4   18  0.3  0.3  1.0  68.8      13 u0_a3237 
        Browser  3355  882    1.1   18  0.2  0.3  1.0  60.8      10 u0_a3355 
 Communications  3402  882    4.0   18  0.2  0.3  1.1  73.1      13 u0_a3402 
       Settings  3517  882    6.7   18  0.6  1.1  4.5  69.0      12 u0_a3517 
      Mochitest  3593  882    1.7   18  0.2  0.3  1.2  64.0      12 u0_a3593 
       FM Radio  5878  882    2.0   18  0.2  0.3  1.2  62.9      12 u0_a5878 
         Geoloc  7005  882    2.6   18  0.4  0.8  4.2  62.9      11 u0_a7005 
       Calendar  7062  882    2.4   18  0.3  0.5  2.6  65.0      12 u0_a7062 
    Marketplace 10446  882    2.3    1  4.3  6.0 11.7  70.0       2 u0_a10446
       Messages 11773  882    3.0   18  0.6  1.5  6.2  67.0      10 u0_a11773
(Preallocated a 12097  882    0.7   18  0.2  0.7  4.2  60.8       1 u0_a12097

System memory info:

            Total 215.3 MB
     Used - cache 185.5 MB
  B2G procs (PSS)  68.1 MB
    Non-B2G procs 117.4 MB
     Free + cache  29.8 MB
             Free   4.4 MB
            Cache  25.4 MB

Low-memory killer parameters:

  notify_trigger 9216 KB

  oom_adj min_free
        0  4096 KB
       58  5120 KB
      117  6144 KB
      352  7168 KB
      470  8192 KB
      588 10240 KB

Comment 50

[(inactive after 6/18) Alive Kuo [:alive]]

Thanks for this.

But according to the output, it's not the issue described here.
You are only having a foreground app(Marketplace).

The problem of bad performance due to multiple background apps is an OOM-killer issue,
but the problem in this bug is talking about we may have more than 2 foreground apps and cannot recover.

That is to say, our QA cannot reproduce this bug, either.

(In reply to Mike Lien[:mlien] from comment #49)
> Actually there have 12 background apps in the meantime on my environment
> The worse performance means launch app and back to homescreen will consume
> more than 1~2 seconds
> 
>                            |     megabytes     |
>            NAME   PID PPID CPU(s) NICE  USS  PSS  RSS VSIZE OOM_ADJ USER     
>             b2g   205    1  185.1    0 42.8 44.4 49.7 242.8       0 root     
>          (Nuwa)   882  205    4.3    0  0.0  0.0  0.6  53.7       0 root     
>      Homescreen   932  882   71.5   18  9.1 10.9 16.8  74.1       8 u0_a932  
>           Video  3037  882    2.4   18  0.2  0.3  1.1  62.9      13 u0_a3037 
>           Music  3236  882    2.4   18  0.2  0.3  1.1  65.9      13 u0_a3236 
>         Gallery  3237  205    2.4   18  0.3  0.3  1.0  68.8      13 u0_a3237 
>         Browser  3355  882    1.1   18  0.2  0.3  1.0  60.8      10 u0_a3355 
>  Communications  3402  882    4.0   18  0.2  0.3  1.1  73.1      13 u0_a3402 
>        Settings  3517  882    6.7   18  0.6  1.1  4.5  69.0      12 u0_a3517 
>       Mochitest  3593  882    1.7   18  0.2  0.3  1.2  64.0      12 u0_a3593 
>        FM Radio  5878  882    2.0   18  0.2  0.3  1.2  62.9      12 u0_a5878 
>          Geoloc  7005  882    2.6   18  0.4  0.8  4.2  62.9      11 u0_a7005 
>        Calendar  7062  882    2.4   18  0.3  0.5  2.6  65.0      12 u0_a7062 
>     Marketplace 10446  882    2.3    1  4.3  6.0 11.7  70.0       2 u0_a10446
>        Messages 11773  882    3.0   18  0.6  1.5  6.2  67.0      10 u0_a11773
> (Preallocated a 12097  882    0.7   18  0.2  0.7  4.2  60.8       1 u0_a12097
> 
> System memory info:
> 
>             Total 215.3 MB
>      Used - cache 185.5 MB
>   B2G procs (PSS)  68.1 MB
>     Non-B2G procs 117.4 MB
>      Free + cache  29.8 MB
>              Free   4.4 MB
>             Cache  25.4 MB
> 
> Low-memory killer parameters:
> 
>   notify_trigger 9216 KB
> 
>   oom_adj min_free
>         0  4096 KB
>        58  5120 KB
>       117  6144 KB
>       352  7168 KB
>       470  8192 KB
>       588 10240 KB

Comment 51

[Gabriele Svelto [:gsvelto] (PTO)]

(In reply to Alive Kuo [:alive][NEEDINFO!] from comment #50)
> The problem of bad performance due to multiple background apps is an
> OOM-killer issue,
> but the problem in this bug is talking about we may have more than 2
> foreground apps and cannot recover.

Looking at that output the issue here seems something entirely different, check this out:

          Video  3037  882    2.4   18  0.2  0.3  1.1  62.9      13 u0_a3037 
          Music  3236  882    2.4   18  0.2  0.3  1.1  65.9      13 u0_a3236 
        Gallery  3237  205    2.4   18  0.3  0.3  1.0  68.8      13 u0_a3237 
        Browser  3355  882    1.1   18  0.2  0.3  1.0  60.8      10 u0_a3355 
 Communications  3402  882    4.0   18  0.2  0.3  1.1  73.1      13 u0_a3402 
       Settings  3517  882    6.7   18  0.6  1.1  4.5  69.0      12 u0_a3517

                                        ^^^

There's no way for those apps to have a USS <1MiB if they've started up correctly. For reference the message app's USS when in the background is ~9MiB.

Comment 52

[Kyle Huey (Exited; not receiving bugmail, old account, do not use)]

They're probably just swapped out.

Comment 53

[Jayme Mercado [:JMercado] (Inactive 3/4/2016)]

On the 2.0 Flame I was unable to reproduce this issue at 319 MB.  I was able to trigger lots of LMK of the foreground app at 256, but I was able to get the same with just opening a single app as well.

Environmental Variables:
Device: Flame 2.0
BuildID: 20140827074629
Gaia: 1de9e49fc7e3e679f589178e6fbd67903b496ca1
Gecko: 83f2f10431a6
Version: 32.0 (2.0) 
Firmware Version: v123
User Agent: Mozilla/5.0 (Mobile; rv:32.0) Gecko/32.0 Firefox/32.0

Comment 54

[Ting-Yu Chou [:ting] (away)]

(In reply to Alive Kuo [:alive][NEEDINFO!] from comment #37)
> (In reply to Tapas  (always NI me) from comment #36)
> > Could you please provide me link to gaia code which does this ? I am just
> > curious to learn more about code which is handling this :)
> 
> https://github.com/mozilla-b2g/gaia/blob/v2.0/apps/system/js/
> app_transition_controller.js#L211

Seems the app is set visible when it's opening, and set invisible when it's closed.

If there're 5 apps launched simutaneously, isn't it possible that they all are visible (foreground) until 4 of them change from closing to closed state and set invisible? Wonder how gaia is different between 1.3 and 2.0 in this part.

Comment 55

[(inactive after 6/18) Alive Kuo [:alive]]

(In reply to Ting-Yu Chou [:ting] from comment #54)
> (In reply to Alive Kuo [:alive][NEEDINFO!] from comment #37)
> > (In reply to Tapas  (always NI me) from comment #36)
> > > Could you please provide me link to gaia code which does this ? I am just
> > > curious to learn more about code which is handling this :)
> > 
> > https://github.com/mozilla-b2g/gaia/blob/v2.0/apps/system/js/
> > app_transition_controller.js#L211
> 
> Seems the app is set visible when it's opening, and set invisible when it's
> closed.
> 
> If there're 5 apps launched simultaneously, isn't it possible that they all
> are visible (foreground) until 4 of them change from closing to closed state
> and set invisible? Wonder how gaia is different between 1.3 and 2.0 in this
> part.

In a normal user operation there will be only two apps involved: one is closing, one is opening.

If we don't care "how to" launch more than three apps simultaneously,
the patch I provided in another bug will close all non-transitioning app whenever there is an app enters opened state. The later comes wins.

However, it seems iOS/Android disallow the user to open apps quickly.

Comment 56

[Tapas[:tkundu on #b2g/gaia/memshrink/gfx] (always NI me)]

(In reply to Alive Kuo [:alive][NEEDINFO!] from comment #55)
> (In reply to Ting-Yu Chou [:ting] from comment #54)
> > (In reply to Alive Kuo [:alive][NEEDINFO!] from comment #37)
> > > (In reply to Tapas  (always NI me) from comment #36)
> > > > Could you please provide me link to gaia code which does this ? I am just
> > > > curious to learn more about code which is handling this :)
> > > 
> > > https://github.com/mozilla-b2g/gaia/blob/v2.0/apps/system/js/
> > > app_transition_controller.js#L211
> > 
> > Seems the app is set visible when it's opening, and set invisible when it's
> > closed.
> > 
> > If there're 5 apps launched simultaneously, isn't it possible that they all
> > are visible (foreground) until 4 of them change from closing to closed state
> > and set invisible? Wonder how gaia is different between 1.3 and 2.0 in this
> > part.
> 
> In a normal user operation there will be only two apps involved: one is
> closing, one is opening.
> 
> If we don't care "how to" launch more than three apps simultaneously,
> the patch I provided in another bug will close all non-transitioning app
> whenever there is an app enters opened state. The later comes wins.
> 
> However, it seems iOS/Android disallow the user to open apps quickly.

I collected following things for FFOS 2.0 which has your fix from bug 1056216 comment 28 :
1) Video for 256MB Flame device 
2) logcat logs
3) b2g-info logs which says >4 apps has became foreground (OOM_ADJ <=2)

here is the log : https://drive.google.com/file/d/0B1cSMS8_GuAEUkU4Q05OWDNrc0k/edit?usp=sharing

My question is why are we allowing more than 2 apps to become foreground app in this usecase ? FFOS needs to run on 256MB and if we are running more than 2 foreground apps then performance will hit badly as LMK won't kill those apps.

Comment 57

[(inactive after 6/18) Alive Kuo [:alive]]

Reading the log, stay tuned.

Comment 58

[(inactive after 6/18) Alive Kuo [:alive]]

Attachment: simple gaia log

Exactly, in the end of the log, all background apps are killed and only one foreground phone app is there.

I don't see there is more than 2 apps has the active class at the same time..

Comment 59

[(inactive after 6/18) Alive Kuo [:alive]]

Attachment: https://github.com/mozilla-b2g/gaia/pull/23411

This patch blocks continuous launchapp request.

Sadly to do this, but since iOS/Android also blocks launching apps too quickly, we are safe to go without changing the mechanism of the transition state machines.

Comment 60

[Ting-Yu Chou [:ting] (away)]

(In reply to Alive Kuo [:alive][NEEDINFO!] from comment #58)
> Exactly, in the end of the log, all background apps are killed and only one
> foreground phone app is there.
> 
> I don't see there is more than 2 apps has the active class at the same time..

I guess this is what should be concerned (from attachment 8480416 [details]):

08-27 21:00:16.508 [Dump: AppWindow][Phone][AppWindow_6][315.354]set visibility -> ,true
08-27 21:00:16.568 [Dump: AppWindow][Messages][AppWindow_1][315.457]set visibility -> ,true
08-27 21:00:16.678 [Dump: AppWindow][Contacts][AppWindow_2][315.518]set visibility -> ,true
08-27 21:00:16.778 [Dump: AppWindow][Browser][AppWindow_3][315.588]set visibility -> ,true
08-27 21:00:16.918 [Dump: AppWindow][Marketplace][AppWindow_4][315.620]set visibility -> ,true
08-27 21:00:17.008 [Dump: AppWindow][Camera][AppWindow_5][315.661]set visibility -> ,true
08-27 21:00:17.088 [Dump: AppWindow][Gallery][AppWindow_8][315.711]set visibility -> ,true
08-27 21:00:17.178 [Dump: AppWindow][Music][AppWindow_9][315.747]set visibility -> ,true
08-27 21:00:17.278 [Dump: AppWindow][Video][AppWindow_10][315.788]set visibility -> ,true

Comment 61

[Tapas[:tkundu on #b2g/gaia/memshrink/gfx] (always NI me)]

Attachment: newlogs.zip

(In reply to Alive Kuo [:alive][NEEDINFO!] from comment #58)
> Created attachment 8480416 [details]
> simple gaia log
> 
> Exactly, in the end of the log, all background apps are killed and only one
> foreground phone app is there.
> 
> I don't see there is more than 2 apps has the active class at the same time..

I tested again with your following patches :
1) new fix proposed by alive in #gaia IRC : https://github.com/mozilla-b2g/gaia/pull/23411
2) fix from bug 1056216 comment 28

here is the b2g-info logs if i kept device in idle state : 
Thu Aug 28 02:29:42 UTC 2014
                          |     megabytes     |
           NAME  PID PPID CPU(s) NICE  USS  PSS  RSS SWAP VSIZE OOM_ADJ USER
            b2g 1041    1   49.3    0 31.2 33.1 36.8 13.8 219.4       0 root
         (Nuwa) 1137 1041    1.7    0  0.1  0.2  0.9  7.1  52.7       0 root
 Communications 3120 1041    3.9    1  0.4  0.6  1.5 14.1  78.2       2 u0_a3120
    Marketplace 3246 1137    4.1    1  0.4  0.7  2.0 13.2  69.8       2 u0_a3246
          Music 3463 1041   23.5    1  0.8  1.0  2.2 11.1  77.1       2 u0_a3463
     Homescreen 3817 1137    4.0    1  4.6  6.1  9.6  9.8  72.6       2 u0_a3817
(Preallocated a 4255 1137    0.7   18  7.0  9.1 13.2  3.1  58.7       1 u0_a4255

System memory info:

            Total 165.9 MB
        SwapTotal 192.0 MB
     Used - cache 138.1 MB
  B2G procs (PSS)  51.0 MB
    Non-B2G procs  87.1 MB
     Free + cache  27.7 MB
             Free   3.4 MB
            Cache  24.3 MB
         SwapFree 104.2 MB

Low-memory killer parameters:

  notify_trigger 14336 KB

  oom_adj min_free
        0  4096 KB
       58  5120 KB
      117  6144 KB
      352  7168 KB
      470  8192 KB
      588 20480 KB


It clearly says there is 4 forground app with OOM_ADJ=2 . And these apps are not going background . I have device in same state. You can get a remote access if you want so :)

Comment 62

[Tapas[:tkundu on #b2g/gaia/memshrink/gfx] (always NI me)]

I discussed with alive in #gaia. I am waiting to see new patch from alive. 
Alive also thinks that he can reproduce this on his own device. But i also have a device ready with foreground apps (OOM_ADJ=2)running FFOS build from comment 61 . Please let me know if you want to do remote debugging in my pc :)

BTW STR is same as I shown in video at Comment 56 and it is reproducible only at 256MB FLAME device (|fastboot oem mem 271|) .

Comment 63

[(inactive after 6/18) Alive Kuo [:alive]]

I updated the same pr https://github.com/mozilla-b2g/gaia/pull/23411 with some more protection:
* if AWM is busy launching, AWF should not instantiate the new appWindow because it is born as foreground.

Comment 64

[Tapas[:tkundu on #b2g/gaia/memshrink/gfx] (always NI me)]

Attachment: newlogs.zip

This is another run with only fix https://github.com/alivedise/gaia/commit/997d7fa6a0e0e3852ef7c7610390b213967cbdb8

I am still seeing that device is running many forground apps > 4 (You can see in b2g-info logs. Search OOM_ADJ=2) 

If i keep device in idle then also I see 3 foreground apps (Homescreen, gallery and music) : 

Thu Aug 28 03:55:02 UTC 2014
                          |     megabytes     |
           NAME  PID PPID CPU(s) NICE  USS  PSS  RSS SWAP VSIZE OOM_ADJ USER
            b2g  289    1   95.9    0 19.5 20.1 21.9 24.8 231.2       0 root
         (Nuwa)  941  289    2.6    0  0.0  0.1  0.4  7.2  52.7       0 root
          Music 2233  289    9.7    1  0.5  0.7  1.9 11.5  77.1       2 u0_a2233
        Gallery 2799  289    9.5    1  1.1  1.3  2.7 10.3  73.6       2 u0_a2799
         Camera 3640  289    5.3    7  9.1  9.8 11.9  8.4  80.9       6 u0_a3640
     Homescreen 3684  941    2.7    1  1.0  1.7  3.7 10.3  63.7       2 u0_a3684
(Preallocated a 4011  941    0.7   18  0.1  0.3  1.4  8.7  56.7       1 u0_a4011

System memory info:

            Total 165.9 MB
        SwapTotal 192.0 MB
     Used - cache 144.9 MB
  B2G procs (PSS)  34.1 MB
    Non-B2G procs 110.9 MB
     Free + cache  20.9 MB
             Free   9.0 MB
            Cache  11.9 MB
         SwapFree  95.4 MB

Low-memory killer parameters:

  notify_trigger 14336 KB

  oom_adj min_free
        0  4096 KB
       58  5120 KB
      117  6144 KB
      352  7168 KB
      470  8192 KB
      588 20480 KB

Device is in same state for remote debugging and STR is also same as I shown in video.

Comment 65

[(inactive after 6/18) Alive Kuo [:alive]]

I updated the patch again:
* Enlong the timer from 500ms to 1000ms.
* If 1000ms is still insufficient, the newly created window will be at background by default.

Comment 66

[Kevin Grandon :kgrandon]

Let's see what the patch does here. Thanks!

Comment 67

[Kevin Grandon :kgrandon]

FWIW it looks like the pull request here contains the updated fix: https://github.com/mozilla-b2g/gaia/pull/23411

Tapas - can you try this patch? Thanks!

Comment 68

[Tapas[:tkundu on #b2g/gaia/memshrink/gfx] (always NI me)]

Attachment: logset2.tar.bz2

(In reply to Kevin Grandon :kgrandon from comment #67)
> FWIW it looks like the pull request here contains the updated fix:
> https://github.com/mozilla-b2g/gaia/pull/23411
> 
> Tapas - can you try this patch? Thanks!

Yes I tried and it also solves bug 1056216 too. 

We are not seeing more than two foreground apps anymore in |b2g-info| logs with this patch.

But we are seeing a new issue . We are seeing that device is running two preallocate app with OOM_ADJ=1 at some point ( I also collected memory report when it happens).

Interesting point is that two preallocate apps does not go away if we keep device idle and it wastes device memory on 256MB target because preallocated process has OOM_ADJ=1 (which is lower than foreground app). 

LMK won't kill multiple preallocate process. LMK can kill foreground app to save these two preallocate process which is totally wrong on 256MB target.

Could you please review this patch and solve this side effects ?

Comment 69

[Tapas[:tkundu on #b2g/gaia/memshrink/gfx] (always NI me)]

Could you please take a look into memory report attached in Comment 68. This is taken when device was idle and it was running two preallocate process.

Comment 71

[Kevin Grandon :kgrandon]

Is this the same as bug 1054011? Some more details about why we didn't think that was a bug in bug 1054011 comment 8.

Comment 72

[Tapas[:tkundu on #b2g/gaia/memshrink/gfx] (always NI me)]

I just read bug 1054011 comment 8. It says that two preallocated processes are created but it goes away after sometime. 

But we are seeing two preallocate process consistently in this case although device is idle for a long time. 

Result will be LMK will kill foreground app but it will try to save two preallocate process.
We shouldn't do this in 256MB device.

Comment 73

[Tapas[:tkundu on #b2g/gaia/memshrink/gfx] (always NI me)]

here is filtered b2g-info logs when it happens : 

Tue Jan  6 22:58:03 UTC 1970
                           |     megabytes     |
           NAME   PID PPID CPU(s) NICE  USS  PSS  RSS SWAP VSIZE OOM_ADJ USER     
            b2g   241    1  214.4    0 36.0 37.1 40.2 21.2 243.4       0 root     
         (Nuwa)  1043  241    4.0    0  0.0  0.1  0.7  7.8  53.8       0 root     
     Homescreen 20079 1043   24.4    1  6.9  8.1 11.9  8.9  75.5       2 u0_a20079
      QCGpsTest 22308 1043    4.0   18  4.2  5.2  8.7  6.6  63.0      10 u0_a22308
(Preallocated a 23149 1043    2.5   18  2.6  3.6  7.1  7.1  60.9       1 u0_a23149
(Preallocated a 23193 1043    2.3   18  2.6  3.6  7.0  7.0  60.9       1 u0_a23193

System memory info:

            Total 167.6 MB
        SwapTotal 192.0 MB
     Used - cache 127.0 MB
  B2G procs (PSS)  57.7 MB
    Non-B2G procs  69.3 MB
     Free + cache  40.6 MB
             Free   7.8 MB
            Cache  32.8 MB
         SwapFree 117.7 MB

Low-memory killer parameters:

  notify_trigger 9216 KB

  oom_adj min_free
        0  4096 KB
       58  5120 KB
      117  6144 KB
      352  7168 KB
      470  8192 KB
      588 10240 KB


And we are seeing that both preallocate processes are forked from NUWA which is not same observation as bug 1054011 comment 8 .

Comment 74

[(inactive after 6/18) Alive Kuo [:alive]]

Please give me logcat, the b2g-info doesn't mean much to me.
BTW preallocated process is not something controllable from gaia so maybe I couldn't help.

Comment 75

[Ting-Yu Chou [:ting] (away)]

bug 1057065 has been resolved for extra prallocated process from Nuwa, could you please double check does the build include the patch?

Comment 76

[Tapas[:tkundu on #b2g/gaia/memshrink/gfx] (always NI me)]

(In reply to Alive Kuo [:alive][NEEDINFO!] from comment #74)
> Please give me logcat, the b2g-info doesn't mean much to me.
> BTW preallocated process is not something controllable from gaia so maybe I
> couldn't help.

logcat logs, b2g-info logs and memory reports are in Comment 68 . 

I also posted some b2g-info logs in Comment 73 which is taken from full logs in Comment 68

Comment 77

[Tapas[:tkundu on #b2g/gaia/memshrink/gfx] (always NI me)]

(In reply to Ting-Yu Chou [:ting] from comment #75)
> bug 1057065 has been resolved for extra prallocated process from Nuwa, could
> you please double check does the build include the patch?

Sorry, Build which I tested for Comment 76 that does not include your patch. I am testing again with your patch. Thanks for pointing out this . 

I will update soon here.

Comment 78

[(inactive after 6/18) Alive Kuo [:alive]]

I don't see something wrong from logcat. That means I need to hand this over to the platform team member because I don't think gaia has anything to do with preallocated process. Sorry.
TingYu, could you help?

Comment 79

[Ting-Yu Chou [:ting] (away)]

(In reply to Alive Kuo [:alive][NEEDINFO!] from comment #78)
> I don't see something wrong from logcat. That means I need to hand this over
> to the platform team member because I don't think gaia has anything to do
> with preallocated process. Sorry.
> TingYu, could you help?

Sure, but let's wait Tapas' update. Note I couldn't repro comment 73.

Comment 80

[Tapas[:tkundu on #b2g/gaia/memshrink/gfx] (always NI me)]

Attachment: logset3.zip

I can still see two foreground apps with both 
1) fix from bug 1057065 : It has already landed.
2) https://github.com/mozilla-b2g/gaia/pull/23411 : Fix from alive 


:alive : Your patch makes it difficult to reproduce this issue. But If I keep trying then I can still hit this issue. 

I am still seeing two foreground apps and it does not goes away even if I keep device idle . BTW device is in same state. If you want then you can remote login to my pc for debugging. 

I attached logcat logs including b2g-info logs. 

I can see two foreground apps are created around timestamp "Thu Jan  1 00:41:55 UTC 1970" in b2g-info logs :
https://pastebin.mozilla.org/6209497

If you try to find device activity in logcat around this timestamp then you may find something interesting. 

Please note that this build includes fix from bug 1057065 and I am not seeing two preallocate process in this testing.

https://pastebin.mozilla.org/6209497

Comment 81

[(inactive after 6/18) Alive Kuo [:alive]]

(In reply to Tapas[:tkundu on #b2g/gaia/memshrink/gfx] (always NI me) from comment #80)
> Created attachment 8481059 [details]
> logset3.zip
> 
> I can still see two foreground apps with both 
> 1) fix from bug 1057065 : It has already landed.
> 2) https://github.com/mozilla-b2g/gaia/pull/23411 : Fix from alive 
> 
> 
> :alive : Your patch makes it difficult to reproduce this issue. But If I
> keep trying then I can still hit this issue. 
> 
> I am still seeing two foreground apps and it does not goes away even if I
> keep device idle . BTW device is in same state. If you want then you can
> remote login to my pc for debugging. 
> 
> I attached logcat logs including b2g-info logs. 
> 
> I can see two foreground apps are created around timestamp "Thu Jan  1
> 00:41:55 UTC 1970" in b2g-info logs :
> https://pastebin.mozilla.org/6209497
> 
> If you try to find device activity in logcat around this timestamp then you
> may find something interesting. 
> 
> Please note that this build includes fix from bug 1057065 and I am not
> seeing two preallocate process in this testing.
> 
> https://pastebin.mozilla.org/6209497

The "search result" is not through the normal app launching path. I guess something triggered rocketbar but not send it to background. I am looking it, but could you repro by some apps other than search result?

Comment 82

[Tapas[:tkundu on #b2g/gaia/memshrink/gfx] (always NI me)]

> The "search result" is not through the normal app launching path. I guess
> something triggered rocketbar but not send it to background. I am looking
> it, but could you repro by some apps other than search result?

I tried for 1 hour but I am not able to reproduce it by some apps other than search result so far. 

I am waiting for new fix from you :)

Comment 83

[(inactive after 6/18) Alive Kuo [:alive]]

(In reply to Tapas[:tkundu on #b2g/gaia/memshrink/gfx] (always NI me) from comment #82)
> > The "search result" is not through the normal app launching path. I guess
> > something triggered rocketbar but not send it to background. I am looking
> > it, but could you repro by some apps other than search result?
> 
> I tried for 1 hour but I am not able to reproduce it by some apps other than
> search result so far. 
> 
> I am waiting for new fix from you :)

I added more logging in the same pr. https://github.com/mozilla-b2g/gaia/pull/23411
Please give me logcat again thanks!

Comment 84

[Tapas[:tkundu on #b2g/gaia/memshrink/gfx] (always NI me)]

alive : I am testing with your patch and I will update soon. BTW could you please raise a bug which will allow us to enable all gaia debug traces dynamically |adb shell setprop XXXXX 1| without rebooting device ? It will be very helpful for debugging stability issues.

Comment 85

[(inactive after 6/18) Alive Kuo [:alive]]

(In reply to Tapas[:tkundu on #b2g/gaia/memshrink/gfx] (always NI me) from comment #84)
> alive : I am testing with your patch and I will update soon. BTW could you
> please raise a bug which will allow us to enable all gaia debug traces
> dynamically |adb shell setprop XXXXX 1| without rebooting device ? It will
> be very helpful for debugging stability issues.

Unfortunately gaia is not able to notice this kind of command. :(

Comment 86

[Tapas[:tkundu on #b2g/gaia/memshrink/gfx] (always NI me)]

(In reply to Alive Kuo [:alive][NEEDINFO!] from comment #85)
> Unfortunately gaia is not able to notice this kind of command. :(

Oh ok. But definitely we can add some native api or do some other thing which can help us to do this type of dynamic logging. We don't want to hit same debugging problem again and again :)

Comment 87

[(inactive after 6/18) Alive Kuo [:alive]]

(In reply to Tapas[:tkundu on #b2g/gaia/memshrink/gfx] (always NI me) from comment #86)
> (In reply to Alive Kuo [:alive][NEEDINFO!] from comment #85)
> > Unfortunately gaia is not able to notice this kind of command. :(
> 
> Oh ok. But definitely we can add some native api or do some other thing
> which can help us to do this type of dynamic logging. We don't want to hit
> same debugging problem again and again :)

https://bugzilla.mozilla.org/show_bug.cgi?id=1060212 is tracking it.

Comment 88

[Tapas[:tkundu on #b2g/gaia/memshrink/gfx] (always NI me)]

Attachment: logset4.zip

(In reply to Alive Kuo [:alive][NEEDINFO!] from comment #83)
> (In reply to Tapas[:tkundu on #b2g/gaia/memshrink/gfx] (always NI me) from
> comment #82)
> > > The "search result" is not through the normal app launching path. I guess
> > > something triggered rocketbar but not send it to background. I am looking
> > > it, but could you repro by some apps other than search result?
> > 
> > I tried for 1 hour but I am not able to reproduce it by some apps other than
> > search result so far. 
> > 
> > I am waiting for new fix from you :)
> 
> I added more logging in the same pr.
> https://github.com/mozilla-b2g/gaia/pull/23411
> Please give me logcat again thanks!


I attached it here.

Comment 89

[Tapas[:tkundu on #b2g/gaia/memshrink/gfx] (always NI me)]

> (In reply to Tapas[:tkundu on #b2g/gaia/memshrink/gfx] (always NI me) from
> comment #82)
>>> The "search result" is not through the normal app launching path. 

Alive: Could you please what are the other apps which are not in 'normal app launching path'  ? it will help me to test your fix in proper way.

I want to make sure that we are handling all corner cases in gaia for this bug.

Comment 90

[(inactive after 6/18) Alive Kuo [:alive]]

(In reply to Tapas[:tkundu on #b2g/gaia/memshrink/gfx] (always NI me) from comment #89)
> > (In reply to Tapas[:tkundu on #b2g/gaia/memshrink/gfx] (always NI me) from
> > comment #82)
> >>> The "search result" is not through the normal app launching path. 
> 
> Alive: Could you please what are the other apps which are not in 'normal app
> launching path'  ? it will help me to test your fix in proper way.
> 
> I want to make sure that we are handling all corner cases in gaia for this
> bug.

It's impossible to fix everything in one bug. AFAIK search app is the only exception but I cannot promise something like *this bug will never happen again I swear*, so sorry.

BTW I believe I had fixed the search app case. it's because visibilityManager doesn't take rocketbar into account.

Try it out.

https://github.com/mozilla-b2g/gaia/pull/23411

Comment 91

[(inactive after 6/18) Alive Kuo [:alive]]

Attachment: Patch for 2.0

Still awaiting final confirmation from :tkundu but ready for review
* Block launchapp request if we are busy
* Block instantiation if we are busy
* VisibilityManager should take searchWindow into account to send homescreen window into background.

Comment 92

[Tim Guan-tin Chien [:timdream] (please needinfo)]

Comment on attachment 8481149 [details] [review]
Patch for 2.0

The better approach should be queue the request instead of throw the request away, but I think that's not doable with the schedule request.

Comment 93

[Gabriele Svelto [:gsvelto] (PTO)]

(In reply to Alive Kuo [:alive][NEEDINFO!] from comment #85)
> Unfortunately gaia is not able to notice this kind of command. :(

For those interested we're discussing adding that feature (enable full gaia logging via props) among other things in bug 881389.

Comment 94

[Gabriele Svelto [:gsvelto] (PTO)]

(In reply to Alive Kuo [:alive][NEEDINFO!] from comment #90)
> BTW I believe I had fixed the search app case. it's because
> visibilityManager doesn't take rocketbar into account.

In another bug it was mentioned that the rocketbar should eventually start using an appWindow like other apps and this should fix this issue without special attention from the system app (bug 967854 comment 3). Kevin do we have a bug already filed for that?

Comment 95

[(inactive after 6/18) Alive Kuo [:alive]]

(In reply to Gabriele Svelto [:gsvelto] from comment #94)
> (In reply to Alive Kuo [:alive][NEEDINFO!] from comment #90)
> > BTW I believe I had fixed the search app case. it's because
> > visibilityManager doesn't take rocketbar into account.
> 
> In another bug it was mentioned that the rocketbar should eventually start
> using an appWindow like other apps and this should fix this issue without
> special attention from the system app (bug 967854 comment 3). Kevin do we
> have a bug already filed for that?

Search app is special for its z level hierarchy. If it becomes a normal appWindow, that means it will be managed by appWindowManager, and we would perform app2app transition each time it is invoked and that's not expected UX.

What really should happen is rocketbar should refactor as a searchWindowManager/searchWindowFactory and we won't be confused.

Comment 96

[Kevin Grandon :kgrandon]

We are about to land a patch which will actually display search on top of app windows. Will this change impact that? Bug 1045817 I believe.

Comment 97

[Tapas[:tkundu on #b2g/gaia/memshrink/gfx] (always NI me)]

Comment on attachment 8481149 [details] [review]
Patch for 2.0

It looks fine to me :)

Comment 98

[(inactive after 6/18) Alive Kuo [:alive]]

(In reply to Kevin Grandon :kgrandon from comment #96)
> We are about to land a patch which will actually display search on top of
> app windows. Will this change impact that? Bug 1045817 I believe.

No unless you remove SearchWindow class and rework one.

Comment 99

[(inactive after 6/18) Alive Kuo [:alive]]

A bad news is: multiple python tests are failing. Investigating, not sure but maybe python test is sending launchapp request continuously..

Comment 100

[(inactive after 6/18) Alive Kuo [:alive]]

(In reply to Alive Kuo [:alive][NEEDINFO!] from comment #99)
> A bad news is: multiple python tests are failing. Investigating, not sure
> but maybe python test is sending launchapp request continuously..

Hi Zac,

Looks like we are launching apps without waiting, and it's causing some problem in real device.
We should launch app by touching icon on homescreen in integration test, but I am afraid we don't have time to do it in a v2.0 blocker. I will add some time.sleep stuff..

Comment 101

[(inactive after 6/18) Alive Kuo [:alive]]

Attachment: Patch for v2.1

I am adding some more sleep to prevent continuous launch request.

Comment 102

[Zac C (:zac)]

Comment on attachment 8482084 [details] [review]
Patch for v2.1

f-, this is not the way to fix tests. Can't you fix or explain the root problem? Is it in the atoms?

Comment 103

[Zac C (:zac)]

Comment on attachment 8482084 [details] [review]
Patch for v2.1

I'm ok with the sleep where we are launching a loop but I'm a bit suspicious of the sleep in test_settings_media_storage (on v2.0 branch pull); it doesn't fit with the reasoning for adding the sleep because it's only one app launching in isolation. We should just be sure we're not covering something up in that scenario.

Comment 104

[(inactive after 6/18) Alive Kuo [:alive]]

The master patch is nearly done (excluding the test_settings_media_storage.py, it's launching an app during the app is closing, which seems impossible for human being operation).

But sadly the v2.0 patch is really bad
https://tbpl.mozilla.org/php/getParsedLog.php?id=47162498&tree=Gaia-Try&full=1

The maxos debugging failures shown here is working *fine* in local gaiatest run. Retrigger the test does not help

I have no idea what happens to tbpl.

Comment 105

[(inactive after 6/18) Alive Kuo [:alive]]

(In reply to Alive Kuo [:alive][NEEDINFO!] from comment #104)
> The master patch is nearly done (excluding the
> test_settings_media_storage.py, it's launching an app during the app is
> closing, which seems impossible for human being operation).
> 
> But sadly the v2.0 patch is really bad
> https://tbpl.mozilla.org/php/getParsedLog.php?id=47162498&tree=Gaia-
> Try&full=1
> 
> The maxos debugging failures shown here is working *fine* in local gaiatest
> run. Retrigger the test does not help
> 
> I have no idea what happens to tbpl.

Update: I had fixed the Gip failure, but now Gij has trouble with continuous launch, too.
https://tbpl.mozilla.org/?rev=18cd828a87aea5c3e1cc0db414815ae9715370d2&tree=Gaia-Try

Comment 106

[(inactive after 6/18) Alive Kuo [:alive]]

After digging, the problem comes from keyboard launch settings in < 1sec.

[marionette log] [AppWindowManager][8.138]launchingapp://keyboard.gaiamobile.org
[marionette log] =====DUMPING APP WINDOWS BEGINS=====
[marionette log] [AppWindow_1]FTU (app://ftu.gaiamobile.org/index.html)
[marionette log] [homescreen]Homescreen (app://verticalhome.gaiamobile.org/index.html#root)
[marionette log] [AppWindow_2]Smart Collections (app://collection.gaiamobile.org/setup.html)
[marionette log] [AppWindow_3]Homescreen (app://homescreen.gaiamobile.org/migrate.html)
[marionette log] [AppWindow_4]Settings (app://settings.gaiamobile.org/index.html#root)
[marionette log] [AppWindow_5]Built-in Keyboard (app://keyboard.gaiamobile.org/settings.html)
[marionette log] =====END OF DUMPING APP WINDOWS=====
[marionette log] [AppWindowManager][8.138] current is app://settings.gaiamobile.org/index.html#root; next is app://keyboard.gaiamobile.org/settings.html
[marionette log] [AppWindowManager][8.139]=== Active app now is: ,Built-in Keyboard,===
[marionette log] [AppWindowManager][8.139]before ready check
[marionette log] [AppWindowManager][8.148]ready to open/closetrue
[marionette log] [AppWindowManager][8.148]=== Active app now is: ,Built-in Keyboard,===
[marionette log] [AppWindowManager][8.150]handling appopening
[marionette log] [AppWindowManager][8.150]launching app ? true:app://keyboard.gaiamobile.org/settings.html
[marionette log] [AppWindowManager][8.150]=== Active app now is: ,Built-in Keyboard,===
[marionette log] [AppWindowManager][8.445]handling appopened
[marionette log] [AppWindowManager][8.445]launching app ? true:app://keyboard.gaiamobile.org/settings.html
[marionette log] [AppWindowManager][8.445]=== Active app now is: ,Built-in Keyboard,===
[marionette log] [System][8.887]launching app://settings.gaiamobile.org/index.html#rootopen-app
[marionette log] [AppWindowManager][8.888]handling launchapp
[marionette log] [AppWindowManager][8.888]launching app ? true:app://keyboard.gaiamobile.org/settings.html
[marionette log] [AppWindowManager][8.888]launchingapp://settings.gaiamobile.org
[marionette log] [AppWindowManager][8.888]Block the app launching request due to busy launching. Ignore app://settings.gaiamobile.org/index.html#root
[marionette log] [AppWindowManager][9.149]launching timeout, clearing flag.

Hi Kevin, after thinking about this issue again,
the previous homescreen seems to block the launch request if there is multiple touch on the icon until the visibility is changed.

I wonder if we could do this to the vertical homescreen again,
because from system app we have difficulty to determine the blocker timer. If we use 500ms it might be too fast for kk qrd device, and if we use 1000ms it is too slow for this kind of test.

I know system app should do something to avoid any quick launch request. but from the view of the blocker,
I tend to encourage vertical homescreen app to block the request before we do such hack in system because we have poor knowledge about who is launching and we may make mistakes like the sleep(1) stuff in gaia tests. Sadly to say, but this bug seems a vertical home regression because it does not block quick launch request like before.

And surely the searchWindow fix is still available for this bug.

Comment 107

[Kevin Grandon :kgrandon]

I think implementing a fix in the vertical homescreen is the wrong way of going about things for a few reasons:

1 - We are exposing a priveleged API for marketplace apps to launch applications - we can't expect them to all implement this workaround. This includes the ability for third party developers to create a replaceable homescreen.
2 - It seems like this is probably still likely to occur with the endless combinations of opening apps with the task manager/zombie apps/edge gestures/activites/etc. 

Is there really no way to have the system app do a full cleaning of everything on an app launch request? We should not be using a timer here, that is bound to lead to race conditions like we are experiencing here.

Nevertheless, I don't mind spinning a patch for this, but for third party homescreen support it seems that we will need this fixed at the system level. Let's just make sure we have a bug filed to do so.

Comment 108

[(inactive after 6/18) Alive Kuo [:alive]]

(In reply to Kevin Grandon :kgrandon from comment #107)
> I think implementing a fix in the vertical homescreen is the wrong way of
> going about things for a few reasons:
> 
> 1 - We are exposing a priveleged API for marketplace apps to launch
> applications - we can't expect them to all implement this workaround. This
> includes the ability for third party developers to create a replaceable
> homescreen.
> 2 - It seems like this is probably still likely to occur with the endless
> combinations of opening apps with the task manager/zombie apps/edge
> gestures/activites/etc. 
> 
> Is there really no way to have the system app do a full cleaning of
> everything on an app launch request? We should not be using a timer here,
> that is bound to lead to race conditions like we are experiencing here.
> 
> Nevertheless, I don't mind spinning a patch for this, but for third party
> homescreen support it seems that we will need this fixed at the system
> level. Let's just make sure we have a bug filed to do so.

Note: this is a v2.0 blocker.

Let's clarify again:
* This is not a system app regression.
* In long term we need to
  - Fix the circular launch transition race in system app. This is about transitions.
  - Decide what to do but definitely not a timer in system app. I suspect this involves more API consideration, for example, mozApp launch needs to tell the caller now it's not launch-able. And more about UX stuff. For low end device we definitely don't want to create lots of apps when the user quickly touches tons of icons in homescreen. This is nothing related to transition but loading tons of apps at the same time is not correct. Sadly to say, system app doesn't have the ability to tell what's should be done.

Comment 109

[Kevin Grandon :kgrandon]

Attachment: Pull request - home screen patch, prevent multiple app launches

I agree that this is not a regression, but at the same time I don't think it's the proper fix. You're right, this is about transitions, but the system app needs to decouple logic from transitions regardless - it should be able to recover it's state no matter how many app launch requests it gets.

I am fine landing this for now though as we all have a lot on our plates. Can you give it a review?

Comment 110

[(inactive after 6/18) Alive Kuo [:alive]]

Comment on attachment 8482838 [details] [review]
Pull request - home screen patch, prevent multiple app launches

Surely r+ but let's see if this fixes tapas' problem.

Tapas, this is another trial to fix your issue, please test it. Also note the issue "search result + homescreen are both foreground" is not included in this patch, I will have another patch for that soon.

Comment 111

[(inactive after 6/18) Alive Kuo [:alive]]

Attachment: Part2: Send homescreen to background while rocketbar is active

This patch is already included in my last patch so no need review.

Comment 112

[Tapas[:tkundu on #b2g/gaia/memshrink/gfx] (always NI me)]

Attachment: logset1.tar.bz2

In b2g-info timestamps, I can see two apps are running with OOM_ADJ=1 and OOM_ADJ=2 between timestamps 'Thu Jan  1 00:21:37 UTC 1970' and 'Thu Jan  1 00:21:52 UTC 1970' .


Thu Jan  1 00:21:37 UTC 1970
                          |     megabytes     |
           NAME  PID PPID CPU(s) NICE  USS  PSS  RSS SWAP VSIZE OOM_ADJ USER    
            b2g  225    1   19.9    0 35.4 38.2 46.5 14.4 247.6       0 root    
         (Nuwa)  982  225    1.2    0  0.3  2.0  8.1  5.4  53.8       0 root    
     Homescreen 1081  982    5.6   18 12.8 16.1 26.0  4.3  82.0       2 u0_a1081
 Communications 1182  982    2.3    0 11.9 15.6 26.0  2.3  71.3       1 u0_a1182
(Preallocated a 1588  982    0.7   18  5.5  8.1 16.4  2.8  59.9       1 u0_a1588


Thu Jan  1 00:21:52 UTC 1970
                          |     megabytes     |
           NAME  PID PPID CPU(s) NICE  USS  PSS  RSS SWAP VSIZE OOM_ADJ USER    
            b2g  225    1   19.9    0 35.4 38.2 46.5 14.4 246.6       0 root    
         (Nuwa)  982  225    1.2    0  0.3  2.0  8.1  5.4  53.8       0 root    
     Homescreen 1081  982    5.6   18 12.8 16.1 26.0  4.3  82.0       2 u0_a1081
 Communications 1182  982    2.3    0 11.9 15.6 26.0  2.3  71.3       1 u0_a1182
(Preallocated a 1588  982    0.7   18  6.0  8.6 17.0  2.6  60.9       1 u0_a1588


I also attached logcat logs when this happened. 
@alive : why Communications app is running with OOM_ADJ=1 for a long time (16 seconds !!) ? This may cause unexpected memory pressure on 256MB device .

Comment 113

[Tapas[:tkundu on #b2g/gaia/memshrink/gfx] (always NI me)]

Attachment: logset2.tar.bz2

We are seeing 3 apps are running as foreground apps between timestamp 
Thu Jan  1 00:42:08 UTC 1970 and Thu Jan  1 00:42:52 UTC 1970

Thu Jan  1 00:42:08 UTC 1970
                          |     megabytes     |
           NAME  PID PPID CPU(s) NICE  USS  PSS  RSS SWAP VSIZE OOM_ADJ USER    
            b2g  226    1  107.7    0 16.7 18.0 22.4 34.7 274.2       0 root    
         (Nuwa)  994  226    2.8    0  0.0  0.1  1.0  7.7  53.8       0 root    
        Dogfood 4784  994    2.6   18  0.3  0.6  2.6 10.7  63.0      10 u0_a4784
      QCGpsTest 5143  226    4.2   18  0.0  0.2  1.9 11.1  68.9      10 u0_a5143
          Music 5240  994    3.8   18  0.3  0.6  3.0 12.4  64.0      10 u0_a5240
       Settings 5369  994    5.9   18  0.3  0.8  3.9 16.4  71.0      10 u0_a5369
     Homescreen 5451  994    9.7   18 16.1 17.2 21.7  7.3  86.6       2 u0_a5451
 Search Results 7283  226    3.1   18  0.4  0.9  4.0 12.7  73.8       6 u0_a7283
 Communications 7350  994    5.1    0  7.6  9.2 14.2 16.2  85.5       1 u0_a7350
         Camera 7930  994    0.9   18  0.6  1.5  5.4  9.5  62.2       2 u0_a7930
plugin-containe 8123  226    0.1   18  0.7  0.7  0.8  0.0  32.0       2 u0_a8123


and 

Thu Jan  1 00:42:52 UTC 1970
                          |     megabytes     |
           NAME  PID PPID CPU(s) NICE  USS  PSS  RSS SWAP VSIZE OOM_ADJ USER    
            b2g  226    1  128.3    0 24.4 26.5 32.1 25.6 259.8       0 root    
         (Nuwa)  994  226    3.2    0  0.0  0.1  0.5  7.8  53.8       0 root    
       Settings 5369  994    8.4    1  5.4  6.8 11.2 11.9  84.8       2 u0_a5369
    Marketplace 8123  226    2.8    1  6.1  7.6 12.2  4.7  68.0       2 u0_a8123
        Gallery 8169  994    2.5    1  9.1 11.6 17.9  6.5  73.0       2 u0_a8169
(Preallocated a 8449  994    1.1   18  4.3  5.9 10.4  5.1  59.9       1 u0_a8449


@alive: If we keep device idle then all apps (except one foreground app) converts to background apps. why are we taking 44seconds to convert multiple foreground apps (Settings, Marketplace, gallery) to background apps ?

Comment 114

[Tapas[:tkundu on #b2g/gaia/memshrink/gfx] (always NI me)]

Comment on attachment 8482838 [details] [review]
Pull request - home screen patch, prevent multiple app launches

I tested this patch and posted my -ve feedback in Comment 112 and Comment 113.

Comment 115

[Tapas[:tkundu on #b2g/gaia/memshrink/gfx] (always NI me)]

@alive: IMO, we should maintain a list of foreground app in system and verify/confirm that we have only app as foreground app when we launch any app. I am not sure how this idea may fit in gaia. But I guess that you will find some way to do it :)

Comment 116

[Gabriele Svelto [:gsvelto] (PTO)]

(In reply to Tapas[:tkundu on #b2g/gaia/memshrink/gfx] (always NI me) from comment #115)
> @alive: IMO, we should maintain a list of foreground app in system and
> verify/confirm that we have only app as foreground app when we launch any
> app. I am not sure how this idea may fit in gaia. But I guess that you will
> find some way to do it :)

That's unrealistic as there's plenty of perfectly valid scenarios where we can have multiple foreground apps. For example having the callscreen minimized in the top bar plus the SMS app open composing a message with the keyboard open. That makes both the callscreen, SMS and keyboard app foreground at the same time and that's fine.

Comment 117

[Tapas[:tkundu on #b2g/gaia/memshrink/gfx] (always NI me)]

(In reply to Gabriele Svelto [:gsvelto] from comment #116)
> (In reply to Tapas[:tkundu on #b2g/gaia/memshrink/gfx] (always NI me) from
> comment #115)
> > @alive: IMO, we should maintain a list of foreground app in system and
> > verify/confirm that we have only app as foreground app when we launch any
> > app. I am not sure how this idea may fit in gaia. But I guess that you will
> > find some way to do it :)
> 
> That's unrealistic as there's plenty of perfectly valid scenarios where we
> can have multiple foreground apps. For example having the callscreen
> minimized in the top bar plus the SMS app open composing a message with the
> keyboard open. That makes both the callscreen, SMS and keyboard app
> foreground at the same time and that's fine.

Ok I have no issues with your 'perfectly valid' cases . But those cases will be very few. So we should handle them especially. But we should fix issues from both Comment 112 and Comment 113 .

Comment 118

[Tim Guan-tin Chien [:timdream] (please needinfo)]

After talking with a few developers in Taipei, we realized bug 1056493 was overlooked to be the possible cause of this bug. That bug didn't land on v2.0 and onwards because there were no symptom on Flame for these branches, however on different hardware the incorrect OOM_ADJ score resulting from that bug could be significant.

Tapas, would you mind applying the patch on that bug and try again? I will definitely start a discussion internally on how to avoid hiccups like this.

Comment 119

[(inactive after 6/18) Alive Kuo [:alive]]

Comment on attachment 8482847 [details] [review]
Part2: Send homescreen to background while rocketbar is active

I tried to update a new homescreen patch which is included in this pr.
Since I have difficulty to repro this issue "AGAIN" on 271MB flame, please help to test this pr.

Comment 120

[(inactive after 6/18) Alive Kuo [:alive]]

Comment on attachment 8482847 [details] [review]
Part2: Send homescreen to background while rocketbar is active

See last comment

Comment 121

[Gabriele Svelto [:gsvelto] (PTO)]

(In reply to Tim Guan-tin Chien [:timdream] (MoCo-TPE) (please ni?) from comment #118)
> After talking with a few developers in Taipei, we realized bug 1056493 was
> overlooked to be the possible cause of this bug. That bug didn't land on
> v2.0 and onwards because there were no symptom on Flame for these branches,
> however on different hardware the incorrect OOM_ADJ score resulting from
> that bug could be significant.

There's another issue that wasn't fixed in that bug: currently we consider the apps under communications/* to be critical hence giving them the highest priority level (FOREGROUND_HIGH) if they're holding a wakelock. That's wrong however, it's a leftover of when communications was handling incoming calls and it wasn't changed when that functionality was split off to the callscreen app. What needs changing is the code here:

https://github.com/mozilla-b2g/gaia/blob/9e2a7c2b82c68231c1afcfcdd8ae9011a38ef611/apps/system/js/browser_frame.js#L92

I'll file a separate bug for that.

Comment 122

[Tim Guan-tin Chien [:timdream] (please needinfo)]

Yeah, we need to clarify if this bug is still about comment 30, where launching multiple apps is visible, or it's just an OOM_ADJ calculation issue originated from window management.

Comment 123

[Gabriele Svelto [:gsvelto] (PTO)]

FYI, I filed bug 1062312 for comment 121.

Comment 124

[Tapas[:tkundu on #b2g/gaia/memshrink/gfx] (always NI me)]

patch in Comment 114 solves issues seen by our test team. But we still need to handle boundary cases like I said in comment 117. 

I will test patch from Comment 120 and update here by tomorrow (may be tonight if I get time) . Sorry for delayed response.

Comment 125

[howie [:howie]]

ping Tapas to see if there's any update.

Comment 126

[(inactive after 6/18) Alive Kuo [:alive]]

Halfway summary:
* Kevin's patch in comment 109 passes Tapas' automation test according to comment 124 but doesn't pass the manual test according to comment 112 and comment 113.
* Comment 112/Comment 113 doesn't include comment 110's fix to avoid the foreground "Search result" as well as homescreen. Not sure why Tapas does not use it but it does not matter now.
* My patch in comment 120, which is an alternative way to fix comment 109 and including comment 110, should fix Tapas' manual test failure. pending.

Comment 127

[Tim Guan-tin Chien [:timdream] (please needinfo)]

Please make sure bug 1056493 was in the tree when we are trying out those patches!

Comment 128

[Tim Guan-tin Chien [:timdream] (please needinfo)]

s/was/is/

Comment 129

[Tapas[:tkundu on #b2g/gaia/memshrink/gfx] (always NI me)]

Comment on attachment 8482847 [details] [review]
Part2: Send homescreen to background while rocketbar is active

This patch looks fine to me . 

I applied only this patch without applying any patch from Comment 110. 

I don't see any new issues which I mentioned in Comment 112/Comment 113. Thanks for good work

Comment 130

[(inactive after 6/18) Alive Kuo [:alive]]

OK let's move forward in our side..
we have *new* integration failure.

1. Vertical Home - Packaged App Failed Download failed state then retry and launch
2. Vertical Home - Packaged App Update resume update
3. Vertical Home - Hosted app failed icon fetch shows icon after a restart
4. Homescreen navigation > Going to the homescreen and back to a warm app

4. is fixed in my side, but 1.2.3. all are related to an installing app.

So for app which is still installing, we will show install dialog and won't send the homescreen app to background. This causes the homescreen app think it's still launching so won't launch any other app again.

Still thinking of how to overcome it. Maybe a timer in homescreen again.

Comment 131

[(inactive after 6/18) Alive Kuo [:alive]]

Patch updated, let's see if all failure gone.

Comment 132

[(inactive after 6/18) Alive Kuo [:alive]]

The only remaining test failure is calendar, but I don't think it's related.

Comment 133

[(inactive after 6/18) Alive Kuo [:alive]]

Comment on attachment 8482847 [details] [review]
Part2: Send homescreen to background while rocketbar is active

Kevin, I hope we could land this in v2.1/master as well because I think the same thing will happen again then. But if you have better idea for the homescreen change we could open followup. What do you think?

Comment 134

[(inactive after 6/18) Alive Kuo [:alive]]

Comment on attachment 8482847 [details] [review]
Part2: Send homescreen to background while rocketbar is active

NOTE: Please see https://wiki.mozilla.org/Release_Management/B2G_Landing to better understand the B2G approval process and landings.

[Approval Request Comment]
[Bug caused by] (feature/regressing bug #):
Caused by Vertical home + rocketbar feature
[User impact] if declined:
Partner requirement
[Testing completed]:
Yes
[Risk to taking this patch] (and alternatives if risky):
This patch prevents user spamming launching app from homescreen because we are having trouble to block such launch request from system app(we will make mistake because we guess the launch request is from homescreen but sometimes it is app2app switch and put a timer in system app will cause intermittent failure). The way to implement is adding a visibilitychange handler in homescreen app and block all launch request until homescreen goes to background. Apparently if homescreen never goes background it will fail but since it passes all tests this way should work.
[String changes made]:
No

Comment 135

[Kevin Grandon :kgrandon]

Alive - can you tell me why you special case and only do this for apps? Don't we want to do this for *all* types of item launches? E.g., a bookmark will open a remote browsing window, couldn't it remain a problem there?

Comment 136

[(inactive after 6/18) Alive Kuo [:alive]]

(In reply to Kevin Grandon :kgrandon from comment #135)
> Alive - can you tell me why you special case and only do this for apps?
> Don't we want to do this for *all* types of item launches? E.g., a bookmark
> will open a remote browsing window, couldn't it remain a problem there?

Ya, but your code has said: we don't have visibilitychange for bookmark(activity) so we cannot recover if we block it :/

On the other side I think we have less problem in handling multiple activities in system side because old homescreen or other app doesn't block continuous activity request from long time before. so I didn't do too much things here.

Comment 137

[(inactive after 6/18) Alive Kuo [:alive]]

(In reply to Alive Kuo [:alive][NEEDINFO!] from comment #136)
> (In reply to Kevin Grandon :kgrandon from comment #135)
> > Alive - can you tell me why you special case and only do this for apps?
> > Don't we want to do this for *all* types of item launches? E.g., a bookmark
> > will open a remote browsing window, couldn't it remain a problem there?
> 
> Ya, but your code has said: we don't have visibilitychange for
> bookmark(activity) so we cannot recover if we block it :/
> 
> On the other side I think we have less problem in handling multiple
> activities in system side because old homescreen or other app doesn't block
> continuous activity request from long time before. so I didn't do too much
> things here.

Sorry, I noticed you are talking about window.open stuff.

After thinking, yes, we may need to consider to block it as well.

Comment 138

[(inactive after 6/18) Alive Kuo [:alive]]

(In reply to Kevin Grandon :kgrandon from comment #135)
> Alive - can you tell me why you special case and only do this for apps?
> Don't we want to do this for *all* types of item launches? E.g., a bookmark
> will open a remote browsing window, couldn't it remain a problem there?

Patch updated.

Comment 139

[Kevin Grandon :kgrandon]

Comment on attachment 8482847 [details] [review]
Part2: Send homescreen to background while rocketbar is active

Looks good, but let's have some guard in the case we don't get a visibilitychange event. I have a feeling we may have a race where an app will get OOM'd during startup and we won't get it due to the 3s delay, hard to test this though.

Comment 140

[(inactive after 6/18) Alive Kuo [:alive]]

It seems tbpl doesn't run for any 2.0 patch right now. https://github.com/mozilla-b2g/gaia/pull/23639

Could you help? Kevin points me out you are the one to ask.

Comment 141

[John Ford [:jhford] CET/CEST Berlin Time]

I'm not sure why it didn't trigger before, but I closed and reopened the PR which resulted in tests being triggered.

Comment 142

[(inactive after 6/18) Alive Kuo [:alive]]

(In reply to John Ford [:jhford] -- please use 'needinfo?' instead of a CC from comment #141)
> I'm not sure why it didn't trigger before, but I closed and reopened the PR
> which resulted in tests being triggered.

Good trick, TY.

Now we are all green https://tbpl.mozilla.org/?rev=65b3f6c6a5b131154686943ea3fd8ff3b40dbba8&tree=Gaia-Try

Comment 143

[(inactive after 6/18) Alive Kuo [:alive]]

(In reply to Alive Kuo [:alive][NEEDINFO!] from comment #134)
> Comment on attachment 8482847 [details] [review]
> Part2: Send homescreen to background while rocketbar is active
> 
> NOTE: Please see https://wiki.mozilla.org/Release_Management/B2G_Landing to
> better understand the B2G approval process and landings.
> 
> [Approval Request Comment]
> [Bug caused by] (feature/regressing bug #):
> Caused by Vertical home + rocketbar feature
> [User impact] if declined:
> Partner requirement
> [Testing completed]:
> Yes
> [Risk to taking this patch] (and alternatives if risky):
> This patch prevents user spamming launching app from homescreen because we
> are having trouble to block such launch request from system app(we will make
> mistake because we guess the launch request is from homescreen but sometimes
> it is app2app switch and put a timer in system app will cause intermittent
> failure). The way to implement is adding a visibilitychange handler in
> homescreen app and block all launch request until homescreen goes to
> background. Apparently if homescreen never goes background it will fail but
> since it passes all tests this way should work.
> [String changes made]:
> No

Note: we are now having a 3sec protection in homescreen app to avoid some edge cases that homescreen will not get visibilitychange and passes all tests so we are okay to go if approved.

Comment 144

[(inactive after 6/18) Alive Kuo [:alive]]

I am going to made another master patch of https://bugzilla.mozilla.org/attachment.cgi?id=8482847 and land it if all tests passed.

Comment 145

[(inactive after 6/18) Alive Kuo [:alive]]

Attachment: Final patch for master

Comment 146

[bhavana bajaj [:bajaj]]

waiting for master landing before uplifting on branches.

Comment 147

[Kevin Grandon :kgrandon]

Alive - Just a FYI that I tested the patch against master and it breaks search on the home screen. The Gij failures on gaia-try might be related.

Comment 148

[(inactive after 6/18) Alive Kuo [:alive]]

(In reply to Kevin Grandon :kgrandon from comment #147)
> Alive - Just a FYI that I tested the patch against master and it breaks
> search on the home screen. The Gij failures on gaia-try might be related.

I had fixed it and all green - landing.
https://github.com/mozilla-b2g/gaia/commit/f5498c1ff6647d34460b1fb3495fc5d214d34ac3

Comment 149

[(inactive after 6/18) Alive Kuo [:alive]]

master and v2.0 patch are all green, I am going to mark master is fixed.

Comment 150

[yang.zhao]

(In reply to Alive Kuo [:alive][NEEDINFO!] from comment #149)
> master and v2.0 patch are all green, I am going to mark master is fixed.
Hi,Alive
  This issue also occurs on v1.4.Could you help to land it on v1.4? Thank you.

Comment 151

[bhavana bajaj [:bajaj]]

Alive, what patch applies to 2.1 here?

Comment 152

[Ryan VanderMeulen [:RyanVM]]

I'm a bit confused about what needs to land where in this bug. Can we just get branch-specific PRs so it's more obvious?

Comment 153

[(inactive after 6/18) Alive Kuo [:alive]]

v2.0
https://github.com/mozilla-b2g/gaia/commit/e5f96624d169a62d24d11fe2ce6ccdac7c4d3087

Comment 154

[(inactive after 6/18) Alive Kuo [:alive]]

(In reply to Ryan VanderMeulen [:RyanVM UTC-4] from comment #152)
> I'm a bit confused about what needs to land where in this bug. Can we just
> get branch-specific PRs so it's more obvious?

https://github.com/mozilla-b2g/gaia/pull/23937 this one could be cherry-picked to v2.1, could you help? thx!

Comment 155

[Ryan VanderMeulen [:RyanVM]]

I can once it gets approval ;)

Comment 156

[(inactive after 6/18) Alive Kuo [:alive]]

Comment on attachment 8487702 [details] [review]
Final patch for master

[Approval Request Comment]
[Bug caused by] (feature/regressing bug #):
[User impact] if declined:
[Testing completed]:
yes
[Risk to taking this patch] (and alternatives if risky):
already running in master so riskless
[String changes made]:
no

Comment 157

[Ryan VanderMeulen [:RyanVM]]

v2.1: https://github.com/mozilla-b2g/gaia/commit/b866e8a70fda3ab5987e6f3b4c6e91788b91a08e

Comment 158

[Kevin Grandon :kgrandon]

Sorry, I've had to back this out for causing bug 1069483 and breaking rocketbar UX. This does not impact v2.0 because the UX is different for that release, so this has not been backed out of v2.0. The problem is that rocketbar is supposed to be semi-transparent over the app content, and this patch makes it fully opaque.

Master revert: https://github.com/mozilla-b2g/gaia/commit/53228a541fca8e8c879d8838d34470639226e2a8
v2.1 revert: https://github.com/mozilla-b2g/gaia/commit/9f3588e8fdd37f6f354b5518dbeab7299b118a9d

Comment 159

[(inactive after 6/18) Alive Kuo [:alive]]

Hmm..could we open followup to address the 2.1/master isssue? We should not leava this bug opened since it's particially fixed in v2.0 and it's confusing to reopen.

Comment 160

[Kai-Zhen Li [:seinlin][:kli]]

v2.0m: https://github.com/mozilla-b2g/gaia/commit/d8f70e1e450b1ab12796b66929382de03db2221d

Comment 161

[Kevin Grandon :kgrandon]

(In reply to Alive Kuo [:alive][NEEDINFO!] from comment #159)
> Hmm..could we open followup to address the 2.1/master isssue? We should not
> leava this bug opened since it's particially fixed in v2.0 and it's
> confusing to reopen.

There probably should be multiple blocking statuses instead. It doesn't make sense to keep it open as a 2.0 blocker, but we could perhaps see if this is a 2.1 blocker? Since this has been fixed in 2.0 and uplifted, we only need a patch for 2.1 now.

Re-nomming for 2.1 instead of 2.0, though we could also do this in another bug.

Comment 162

[Tim Guan-tin Chien [:timdream] (please needinfo)]

Let's try to fix this again in v2.1

Comment 163

[(inactive after 6/18) Alive Kuo [:alive]]

(In reply to Kevin Grandon :kgrandon from comment #161)
> (In reply to Alive Kuo [:alive][NEEDINFO!] from comment #159)
> > Hmm..could we open followup to address the 2.1/master isssue? We should not
> > leava this bug opened since it's particially fixed in v2.0 and it's
> > confusing to reopen.
> 
> There probably should be multiple blocking statuses instead. It doesn't make
> sense to keep it open as a 2.0 blocker, but we could perhaps see if this is
> a 2.1 blocker? Since this has been fixed in 2.0 and uplifted, we only need a
> patch for 2.1 now.
> 
> Re-nomming for 2.1 instead of 2.0, though we could also do this in another
> bug.

I am not able to reproduce bug 1069483 with master patch. What's the exact STR?

Comment 164

[(inactive after 6/18) Alive Kuo [:alive]]

(In reply to Alive Kuo [:alive][NEEDINFO!] from comment #163)
> (In reply to Kevin Grandon :kgrandon from comment #161)
> > (In reply to Alive Kuo [:alive][NEEDINFO!] from comment #159)
> > > Hmm..could we open followup to address the 2.1/master isssue? We should not
> > > leava this bug opened since it's particially fixed in v2.0 and it's
> > > confusing to reopen.
> > 
> > There probably should be multiple blocking statuses instead. It doesn't make
> > sense to keep it open as a 2.0 blocker, but we could perhaps see if this is
> > a 2.1 blocker? Since this has been fixed in 2.0 and uplifted, we only need a
> > patch for 2.1 now.
> > 
> > Re-nomming for 2.1 instead of 2.0, though we could also do this in another
> > bug.
> 
> I am not able to reproduce bug 1069483 with master patch. What's the exact
> STR?

After rebasing to master it is repro-ed....ok somebody regresses this and my patch reveals that :/

Comment 165

[(inactive after 6/18) Alive Kuo [:alive]]

(In reply to Alive Kuo [:alive][NEEDINFO!] from comment #164)
> (In reply to Alive Kuo [:alive][NEEDINFO!] from comment #163)
> > (In reply to Kevin Grandon :kgrandon from comment #161)
> > > (In reply to Alive Kuo [:alive][NEEDINFO!] from comment #159)
> > > > Hmm..could we open followup to address the 2.1/master isssue? We should not
> > > > leava this bug opened since it's particially fixed in v2.0 and it's
> > > > confusing to reopen.
> > > 
> > > There probably should be multiple blocking statuses instead. It doesn't make
> > > sense to keep it open as a 2.0 blocker, but we could perhaps see if this is
> > > a 2.1 blocker? Since this has been fixed in 2.0 and uplifted, we only need a
> > > patch for 2.1 now.
> > > 
> > > Re-nomming for 2.1 instead of 2.0, though we could also do this in another
> > > bug.
> > 
> > I am not able to reproduce bug 1069483 with master patch. What's the exact
> > STR?
> 
> After rebasing to master it is repro-ed....ok somebody regresses this and my
> patch reveals that :/

But now I cannot even see disappearing of rocketbar result overlay. Kevin, could you try again?
https://github.com/mozilla-b2g/gaia/pull/24372

Comment 166

[Kevin Grandon :kgrandon]

(In reply to Alive Kuo [:alive][NEEDINFO!] from comment #165)
> But now I cannot even see disappearing of rocketbar result overlay. Kevin,
> could you try again?
> https://github.com/mozilla-b2g/gaia/pull/24372

When you focus rocketbar, you should see the app window below it. This is important as we are changing this soon to be an even light color. I've tried the new patch, and the issue is still there - you can not see the app beneath the rocketbar when it is open. It's very hard to see in master, but it is there.

Also I feel that this is a band-aid that probably should only be applied to 2.1 if we need to as we are soon going to be getting replaceable home screens. One thing that might be nice to see is if we have all instant transitions in the system app (transitionController = null), does this issue reproduce?

Comment 167

[(inactive after 6/18) Alive Kuo [:alive]]

(In reply to Kevin Grandon :kgrandon from comment #166)
> (In reply to Alive Kuo [:alive][NEEDINFO!] from comment #165)
> > But now I cannot even see disappearing of rocketbar result overlay. Kevin,
> > could you try again?
> > https://github.com/mozilla-b2g/gaia/pull/24372
> 
> When you focus rocketbar, you should see the app window below it. This is
> important as we are changing this soon to be an even light color. I've tried
> the new patch, and the issue is still there - you can not see the app
> beneath the rocketbar when it is open. It's very hard to see in master, but
> it is there.
> 
> Also I feel that this is a band-aid that probably should only be applied to
> 2.1 if we need to as we are soon going to be getting replaceable home
> screens. One thing that might be nice to see is if we have all instant
> transitions in the system app (transitionController = null), does this issue
> reproduce?

This is not a bug. This is what :tkunda wants to fix in this bug - there should be no two foreground app when rocketbar is opened. If we don't put the active app to background he will argue again. Please re-read this bug and argue with him if you think we should not fix.

The real problem is backend - the gecko tightly bind page visibility and rendering. Please check https://bugzilla.mozilla.org/show_bug.cgi?id=1034001 as it's the proper fix.

BTW there's nothing related to transition.

Comment 168

[(inactive after 6/18) Alive Kuo [:alive]]

Hi Tapas, please see comment 166 and comment 167.
When rocketbar is opened if we send the active app to background as comment 166 it was treated as a bug. What do you think if we drop this fix only for rocketbar(The "Search result")?

Comment 169

[Kevin Grandon :kgrandon]

Yes, for rocketbar use-cases we need two foreground apps. We can have the fix, but not for rocketbar cases. Tapas let us know what you think. Thanks.

Comment 170

[Tapas[:tkundu on #b2g/gaia/memshrink/gfx] (always NI me)]

(In reply to Kevin Grandon :kgrandon from comment #169)
> Yes, for rocketbar use-cases we need two foreground apps. We can have the
> fix, but not for rocketbar cases. Tapas let us know what you think. Thanks.

Can you please explain me why do we need two foreground app for "search results " ?

Comment 171

[Kevin Grandon :kgrandon]

(In reply to Tapas[:tkundu on #b2g/gaia/memshrink/gfx] (always NI me) from comment #170)
> (In reply to Kevin Grandon :kgrandon from comment #169)
> > Yes, for rocketbar use-cases we need two foreground apps. We can have the
> > fix, but not for rocketbar cases. Tapas let us know what you think. Thanks.
> 
> Can you please explain me why do we need two foreground app for "search
> results " ?

Rocketbar results overlay the actual app. You can see both the rocketbar search results, as well as the app beneath it. This is by UX design.

This is more apparent in the latest 2.2 branch in which the opacity of the overlay is lighter than 2.1 - and it's likely that the polish might be uplifted to 2.1.

If this is causing problems, one alternative might be to change the UX, or maybe do something with a screenshot. Though we may cause additional performance problems by changing to a screenshot.

Comment 172

[Tapas[:tkundu on #b2g/gaia/memshrink/gfx] (always NI me)]

(In reply to Kevin Grandon :kgrandon from comment #171)
> (In reply to Tapas[:tkundu on #b2g/gaia/memshrink/gfx] (always NI me) from
> comment #170)
> > (In reply to Kevin Grandon :kgrandon from comment #169)
> > > Yes, for rocketbar use-cases we need two foreground apps. We can have the
> > > fix, but not for rocketbar cases. Tapas let us know what you think. Thanks.
> > 
> > Can you please explain me why do we need two foreground app for "search
> > results " ?
> 
> Rocketbar results overlay the actual app. You can see both the rocketbar
> search results, as well as the app beneath it. This is by UX design.
> 
We are fine with this rocketbar issue as long as it is needed by US design.

Comment 173

[Kevin Grandon :kgrandon]

Forwarding the ni? to Alive. Alive - it seems like the rocketbar use-case can stay for now.

Do we need to solve this in other areas still for 2.1+?

Comment 174

[(inactive after 6/18) Alive Kuo [:alive]]

(In reply to Kevin Grandon :kgrandon from comment #171)
> (In reply to Tapas[:tkundu on #b2g/gaia/memshrink/gfx] (always NI me) from
> comment #170)
> > (In reply to Kevin Grandon :kgrandon from comment #169)
> > > Yes, for rocketbar use-cases we need two foreground apps. We can have the
> > > fix, but not for rocketbar cases. Tapas let us know what you think. Thanks.
> > 
> > Can you please explain me why do we need two foreground app for "search
> > results " ?
> 
> Rocketbar results overlay the actual app. You can see both the rocketbar
> search results, as well as the app beneath it. This is by UX design.
> 
> This is more apparent in the latest 2.2 branch in which the opacity of the
> overlay is lighter than 2.1 - and it's likely that the polish might be
> uplifted to 2.1.
> 
> If this is causing problems, one alternative might be to change the UX, or
> maybe do something with a screenshot. Though we may cause additional
> performance problems by changing to a screenshot.

I believe the long term solution is
https://bugzilla.mozilla.org/show_bug.cgi?id=1034001 or
https://bugzilla.mozilla.org/show_bug.cgi?id=1061969

Comment 175

[(inactive after 6/18) Alive Kuo [:alive]]

(In reply to Kevin Grandon :kgrandon from comment #173)
> Forwarding the ni? to Alive. Alive - it seems like the rocketbar use-case
> can stay for now.
> 
> Do we need to solve this in other areas still for 2.1+?

I will make a new patch for 2.1/master without rocketbar change.

Comment 176

[(inactive after 6/18) Alive Kuo [:alive]]

Attachment: patch for master, v6

Comment 177

[(inactive after 6/18) Alive Kuo [:alive]]

Attachment: patch for v2.1 (v6)

Comment 178

[(inactive after 6/18) Alive Kuo [:alive]]

Comment on attachment 8497417 [details] [review]
patch for master, v6

Let's do the final check and land this version without rocketbar fix.

[Approval Request Comment]
[Bug caused by] (feature/regressing bug #):
[User impact] if declined:
[Testing completed]:
[Risk to taking this patch] (and alternatives if risky):
[String changes made]:

Please see https://bugzilla.mozilla.org/show_bug.cgi?id=1055299#c134

The difference is the rocketbar change is removed in this patch.

Comment 179

[[:fabrice] Fabrice Desré]

Comment on attachment 8497417 [details] [review]
patch for master, v6

Please don't ask for approval on patches that are not even on master.

Comment 180

[(inactive after 6/18) Alive Kuo [:alive]]

Removed the unwanted change and landed since all green.
https://github.com/mozilla-b2g/gaia/pull/24649

Comment 181

[(inactive after 6/18) Alive Kuo [:alive]]

Comment on attachment 8497417 [details] [review]
patch for master, v6

[Approval Request Comment]
[Bug caused by] (feature/regressing bug #): vertical home landed
[User impact] if declined: be able to open serveral apps while one app is still opening
[Testing completed]: all green on tbpl
[Risk to taking this patch] (and alternatives if risky): no
[String changes made]: no

Comment 182

[Ryan VanderMeulen [:RyanVM]]

v2.1: https://github.com/mozilla-b2g/gaia/commit/7951a7929a88f5b420c8216e86beacceaada8769

Comment 183

[Yeojin Chung [:YeojinC]]

Unable to verify the issue. I was not able to open multiple apps simultaneously. When I select 3 apps fast on the Homescreen, only the first app is launched. (Both 256mb and 319mb)

Device: Flame 2.1 (256mb/319mb)(Kitkat Base)(Full Flash)
BuildID: 20141029001202
Gaia: eb0aab0f13c78c7ac378ad860e865c4b6eaf669f
Gecko: 318019f80a8e
Gonk: 48835395daa6a49b281db62c50805bd6ca24077e
Version: 34.0 (2.1) 
Firmware Version: v188
User Agent: Mozilla/5.0 (Mobile; rv:34.0) Gecko/34.0 Firefox/34.0

Comment 184

[Sue]

Unable to verify the issue on Flame2.0/2.1/2.2 and Woodduck 2.0M. I was not able to open multiple apps simultaneously. When I select 3 apps fast on the Homescreen, only the first app is launched.

Flame 2.0 build:
Gaia-Rev        736933b25ded904f0cb935a0d48f1f3cf91d33ad
Gecko-Rev       https://hg.mozilla.org/releases/mozilla-b2g32_v2_0/rev/6ff30f9ba931
Build-ID        20150120000224
Version         32.0
Device-Name     flame
FW-Release      4.4.2
FW-Incremental  eng.cltbld.20150120.035201
FW-Date         Tue Jan 20 03:52:11 EST 2015
Bootloader      L1TC000118D0

Flame 2.1 build:
Gaia-Rev        77c57eb8a985d5cbd34a597fb1b978ba6e205af6
Gecko-Rev       https://hg.mozilla.org/releases/mozilla-b2g34_v2_1/rev/f05d0a2d2378
Build-ID        20150120001202
Version         34.0
Device-Name     flame
FW-Release      4.4.2
FW-Incremental  eng.cltbld.20150120.035022
FW-Date         Tue Jan 20 03:50:33 EST 2015
Bootloader      L1TC000118D0

Flame 2.2 build:
Gaia-Rev        f5b3d1b6cfa3e702033f613915ae637cb735cbfb
Gecko-Rev       https://hg.mozilla.org/releases/mozilla-b2g37_v2_2/rev/5d7497ce4cc7
Build-ID        20150120002507
Version         37.0a2
Device-Name     flame
FW-Release      4.4.2
FW-Incremental  eng.cltbld.20150120.035540
FW-Date         Tue Jan 20 03:55:51 EST 2015
Bootloader      L1TC000118D0

Woodduck build:
Gaia-Rev        8b2e62a69dc6da9d064b6f2ea42b61fcc11b6685
Gecko-Rev       35614bb51c33caccaa2b83b3226109a80a7a46d2
Build-ID        20150120050313
Version         32.0
Device-Name     jrdhz72_w_ff
FW-Release      4.4.2
FW-Incremental  1421701500
FW-Date         Tue Jan 20 05:05:18 CST 2015