1038435 - [B2G][Perf] User cannot use the back button when they go from browser, to card view, and back to browser due to higher memory use in Gaia

Status: RESOLVED FIXED

(Firefox OS Graveyard :: Performance, defect, P1)

Description

[Derek Harris [:DerekH] - Dont need info. Last day 6/5/15]

Attachment: BackButton.txt

Description:
If the user is browsing the internet then they go into card view, and then tap back into the browser app, the back button will become greyed out and the user can no longer use it.

Prerequisite: Have wifi enabled

Repro Steps:
1) Update a Flame to Build ID: 20140714000202
2) Open Browser app> visit at least 2 websites
3) Once the back button is available, Hold the home button to go to card view
4) Tap back into browser app> Observe Back button

Actual:
Back button is greyed out and unavailable

Expected:
The user is able to use the back button after visiting multiple websites

Flame 2.0

Environmental Variables:
Device: Flame 2.0
BuildID: 20140714000202
Gaia: ca022f811bcbbda0f89086094a9e92bb220fea18
Gecko: 376889ab0e02
Version: 32.0a2 (2.0)
Firmware Version: v122
User Agent: Mozilla/5.0 (Mobile; rv:32.0) Gecko/32.0 Firefox/32.0

Keywords: Back, Forward, Card View, Task Manager, Homescreen,

Notes: This will also work most of the time if the user just backs out to the homescreen, instead of going to card view

Repro frequency: 100%
See attached: Logcat, Video - http://youtu.be/NDSQ8Eug6Tk

Comment 1

[Derek Harris [:DerekH] - Dont need info. Last day 6/5/15]

This issue DOES occur on Flame 2.1

The back button becomes unavailable in the browser

Flame 2.1 (273mb)

Environmental Variables:
Device: Flame Master
Build ID: 20140714040201
Gaia: 88e0a972280bb35847c010b8c3f1481fa80f3847
Gecko: f7aef4fc9d47
Version: 33.0a1 (Master)
Firmware Version: v122
User Agent: Mozilla/5.0 (Mobile; rv:33.0) Gecko/33.0 Firefox/33.0


This issue does NOT occur on Buri 2.1, Open C 2.1 Flame 2.0(512mb), Buri 2.0, Open C 2.0, Flame 1.4, Buri 1.4, Open C 1.4, or Flame base v122

The user is able to use the back button after backing out of the browser app and then going back in

Buri 2.1

Environmental Variables:
Device: Buri Master
Build ID: 20140714073123
Gaia: 88e0a972280bb35847c010b8c3f1481fa80f3847
Gecko: 340b19c14d3d
Version: 33.0a1 (Master) MOZ
Firmware Version: v1.2device.cfg
User Agent: Mozilla/5.0 (Mobile; rv:33.0) Gecko/33.0 Firefox/33.0


Open C 2.1

Environmental Variables:
Device: Open_C Master
Build ID: 20140714040201
Gaia: 88e0a972280bb35847c010b8c3f1481fa80f3847
Gecko: f7aef4fc9d47
Version: 33.0a1 (Master)
Firmware Version: P821A10V1.0.0B06_LOG_DL
User Agent: Mozilla/5.0 (Mobile; rv:33.0) Gecko/33.0 Firefox/33.0


Flame 2.0 (512mb)

Environmental Variables:
Device: Flame 2.0
BuildID: 20140714000202
Gaia: ca022f811bcbbda0f89086094a9e92bb220fea18
Gecko: 376889ab0e02
Version: 32.0a2 (2.0)
Firmware Version: v122
User Agent: Mozilla/5.0 (Mobile; rv:32.0) Gecko/32.0 Firefox/32.0


Buri 2.0

Environmental Variables:
Device: Buri 2.0
BuildID: 20140714000202
Gaia: ca022f811bcbbda0f89086094a9e92bb220fea18
Gecko: 376889ab0e02
Version: 32.0a2 (2.0)
Firmware Version: v1.2device.cfg
User Agent: Mozilla/5.0 (Mobile; rv:32.0) Gecko/32.0 Firefox/32.0


Open C 2.0

Environmental Variables:
Device: Open_C 2.0
Build ID: 20140714000202
Gaia: ca022f811bcbbda0f89086094a9e92bb220fea18
Gecko: 376889ab0e02
Version: 32.0a2 (2.0)
Firmware Version: P821A10V1.0.0B06_LOG_DL
User Agent: Mozilla/5.0 (Mobile; rv:32.0) Gecko/32.0 Firefox/32.0


Flame 1.4 (273mb)

Environmental Variables:
Device: Flame 1.4
Build ID: 20140714000206
Gaia: b7d36622c7df92c976c37520ccab25199c7ada91
Gecko: dbebcdab47aa
Version: 30.0 (1.4)
Firmware Version: v122
User Agent: Mozilla/5.0 (Mobile; rv:30.0) Gecko/30.0 Firefox/30.0


Buri 1.4

Environmental Variables:
Device: Buri 1.4
Build ID: 20140714000206
Gaia: b7d36622c7df92c976c37520ccab25199c7ada91
Gecko: dbebcdab47aa
Version: 30.0 (1.4)
Firmware Version: v1.2device.cfg
User Agent: Mozilla/5.0 (Mobile; rv:30.0) Gecko/30.0 Firefox/30.0


Open C 1.4

Environmental Variables:
Device: Open_C 1.4
Build ID: 20140714000206
Gaia: b7d36622c7df92c976c37520ccab25199c7ada91
Gecko: dbebcdab47aa
Version: 30.0 (1.4)
Firmware Version: P821A10V1.0.0B06_LOG_DL
User Agent: Mozilla/5.0 (Mobile; rv:30.0) Gecko/30.0 Firefox/30.0


Flame v122

Environmental Variables:
Device: Flame 1.3
Build ID: 20140616171114
Gaia: e1b7152715072d27e0880cdc6b637f82fa42bf4e
Gecko: e181a36ebafaa24e5390db9f597313406edfc794
Version: 28.0 (1.3)
Firmware Version: v122
User Agent: Mozilla/5.0 (Mobile; rv:28.0) Gecko/28.0 Firefox/28.0


Flame Base v121-2

Environmental Variables:
Device: Flame 1.3
Build ID: 20140610200025
Gaia: e106a3f4a14eb8d4e10348efac7ae6dea2c24657
Gecko: b637b0677e15318dcce703f0358b397e09b018af
Version: 28.0 (1.3) 
Firmware Version: v121-2
User Agent: Mozilla/5.0 (Mobile; rv:28.0) Gecko/28.0 Firefox/28.0

Comment 2

[Joshua Mitchell (Inactive)]

nomming as a 2.0 blocker -  STR includes a commonly used flow (From Browser to Card View and Back - any user shutting down other apps to try and increase their browser speed is common) and Browser is a very popular feature to use.

Comment 3

[Ben Francis [:benfrancis]]

It looks like the browser tab is getting killed due to low memory and when a browser process gets killed the session history goes with it.

I doubt this is a regression and the fix is probably to add a new session restore feature to Gecko which can be accessed via the Browser API so that session history can be restored after a browser process gets killed.

Comment 4

[Gregor Wagner [:gwagner]]

Can we verify that this only occurs on a 256MB device?

Comment 5

[Ben Francis [:benfrancis]]

Kan-Ru, do you think there should be an API for this, or should Gecko somehow handle it automagically?

Comment 6

[Johan Lorenzo [:jlorenzo]]

(In reply to Gregor Wagner [:gwagner] from comment #4)
> Can we verify that this only occurs on a 256MB device?

As per comment 1, it only occurs with 256MB (273MB) Flame devices with 2.0 or 2.1.

Comment 7

[Kan-Ru Chen [:kanru] (UTC+9)]

(In reply to Ben Francis [:benfrancis] from comment #5)
> Kan-Ru, do you think there should be an API for this, or should Gecko
> somehow handle it automagically?

See bug 1033999. I think gecko should handle it automagically and maybe having some way to control it.

Comment 8

[[:fabrice] Fabrice Desré]

(In reply to Kan-Ru Chen [:kanru] from comment #7)
> (In reply to Ben Francis [:benfrancis] from comment #5)
> > Kan-Ru, do you think there should be an API for this, or should Gecko
> > somehow handle it automagically?
> 
> See bug 1033999. I think gecko should handle it automagically and maybe
> having some way to control it.

I agree. We probably still want gecko to fire something like "sessionrestorestart"/ "sessionrestoreend" on mozbrowser if gaia wants to do something fancy.

Comment 9

[Jason Smith [:jsmith]]

(In reply to Ben Francis [:benfrancis] from comment #3)
> It looks like the browser tab is getting killed due to low memory and when a
> browser process gets killed the session history goes with it.
> 
> I doubt this is a regression and the fix is probably to add a new session
> restore feature to Gecko which can be accessed via the Browser API so that
> session history can be restored after a browser process gets killed.

This is wrong. The branch checking above clearly indicates that this was working with low memory on 273 MB on 1.4 & busted on 2.0. Sending back over to the Gaia:Browser and renoming to keep the focus on what the *regressed* in the bug.

In the future, let's not confuse feature work with regressions in existing behavior.

I'm +ing this because I happen to agree with the reporter - this is common use case that should work.

Comment 10

[Candice Serran (:cserran)]

Johan can you please verify that this is/isn't a memory issue today?

Comment 11

[Peter Dolanjski [:pdol]]

(In reply to Jason Smith [:jsmith] - PTO 7/14 - 7/18 from comment #9)
> (In reply to Ben Francis [:benfrancis] from comment #3)
> > It looks like the browser tab is getting killed due to low memory and when a
> > browser process gets killed the session history goes with it.
> > 
> > I doubt this is a regression and the fix is probably to add a new session
> > restore feature to Gecko which can be accessed via the Browser API so that
> > session history can be restored after a browser process gets killed.
> 
> This is wrong. The branch checking above clearly indicates that this was
> working with low memory on 273 MB on 1.4 & busted on 2.0. Sending back over
> to the Gaia:Browser and renoming to keep the focus on what the *regressed*
> in the bug.

Isn't this likely a symptom of the overall 2.0 memory issue? (not necessarily a regression in Browser, specifically)

Comment 12

[Ben Francis [:benfrancis]]

(In reply to Jason Smith [:jsmith] - PTO 7/14 - 7/18 from comment #9)
> This is wrong. The branch checking above clearly indicates that this was
> working with low memory on 273 MB on 1.4 & busted on 2.0. Sending back over
> to the Gaia:Browser and renoming to keep the focus on what the *regressed*
> in the bug.

This is not a regression in the browser app, this code has not changed. If you disagree then please tell me which commit in the browser app caused the regression.

This is easy to reproduce by killing a browser tab content process in the terminal, you will see that the session history gets killed with it. The only way to prevent this happening in low memory situations is to add session restore features to Gecko.

As Peter says, if there is a regression between 1.4 and 2.0 it is "Gaia uses more memory" and doesn't work so well on the Flame if the RAM is arbitrarily reduced to 273MB. That is not particularly actionable in this bug.

Comment 13

[Johan Lorenzo [:jlorenzo]]

This is an overall memory issue. With today's 1.4 build, I am able to reproduce the issue if I go twice in the cards views. Detailed STR: 
1. Connect to a Wi-Fi hotspot.
2. Restart the device.
3. Open Browser app.
4. Go to https://www.mozilla.org/en-US/firefox/os/ (one of the pre-existing bookmarks) and let the page load.
5. Go to the bottom of the page and click to the Mozilla's Twitter link. 
6. Once the page is loaded, hold the home button to go to card view.
7. Tap back into browser app.
8. Repeat step 6 and 7 => The page will reload and the back button won't be available.

Here below, the memory info (in MB) before and after the page reloading.

v1.4 - before
      NAME  PID PPID CPU(s) NICE  USS  PSS  RSS VSIZE OOM_ADJ USER
       b2g  317    1   62.0    0 38.6 40.7 45.6 185.4       0 root
    (Nuwa)  889  317    1.3    0  0.0  0.7  3.1  51.1       0 root
Homescreen 1089  889    3.1   18  8.8 10.6 15.1  68.2       8 u0_a1089
   Browser 1212  317   19.4    1 14.3 16.5 21.2  98.5       2 u0_a1212

v1.4 - after
      NAME  PID PPID CPU(s) NICE  USS  PSS  RSS VSIZE OOM_ADJ USER
       b2g  317    1   67.8    0 34.9 38.0 43.8 194.9       0 root
    (Nuwa)  889  317    1.5    0  0.2  1.0  3.4  51.1       0 root
Homescreen 1089  889    3.3   18  0.7  2.5  7.0  68.2       8 u0_a1089
   Browser 1469  317    5.6    1 31.7 34.7 40.5  99.4       2 u0_a1469

v2.0 - before
           NAME  PID PPID CPU(s) NICE  USS  PSS  RSS VSIZE OOM_ADJ USER
            b2g  292    1   67.8    0 47.7 49.3 51.7 229.9       0 root
         (Nuwa)  893  292    1.2    0  0.0  0.3  1.1  52.6       0 root
        Browser 1102  893   23.8    1 27.5 29.0 31.2 113.3       2 u0_a1102
(Preallocated a 1283  893    1.1   18  0.0  0.5  1.8  58.6       1 u0_a1283

v2.0 - after
           NAME  PID PPID CPU(s) NICE  USS  PSS  RSS VSIZE OOM_ADJ USER
            b2g  292    1   82.0    0 45.3 46.3 48.4 226.4       0 root
         (Nuwa)  893  292    1.3    0  0.0  0.2  1.0  52.6       0 root
     Homescreen 1283  893    6.1    7  9.3 10.1 11.9  89.0       6 u0_a1283
        Browser 1631  893    7.4    1 10.8 11.5 13.2 109.4       2 u0_a1631
(Preallocated a 1650  893    0.9   18  3.1  3.8  5.5  58.6       1 u0_a1650

Comment 14

[Jason Smith [:jsmith]]

Johan - comment 13 is *not* the same bug here. The tester did not go to the card view twice here to reproduce the bug, he went once. Resetting flags here.

Comment 15

[Johan Lorenzo [:jlorenzo]]

I don't agree. The tester hit an OOM with his STR. Have a look at the attached logcat: "07-14 15:27:25.905: E/OomLogger(293): [Kill]: send sigkill to 13266 (Browser), adj 134, size 3359".

To my understanding, if it was a regular regression, the issue would occur on 2.0 with 512MB but it doesn't.

Jason, if it's not an OOM, what kind of regression are you thinking about?

Comment 16

[Jason Smith [:jsmith]]

(In reply to Johan Lorenzo [:jlorenzo] from comment #15)
> I don't agree. The tester hit an OOM with his STR. Have a look at the
> attached logcat: "07-14 15:27:25.905: E/OomLogger(293): [Kill]: send sigkill
> to 13266 (Browser), adj 134, size 3359".
> 
> To my understanding, if it was a regular regression, the issue would occur
> on 2.0 with 512MB but it doesn't.
> 
> Jason, if it's not an OOM, what kind of regression are you thinking about?

OOMs can be hit for multiple reasons. One STR might have a different root cause for an OOM then another STR that generates an OOM. The STRs are not the same, so they are the not same bug.

In order to see this reproduce on 1.4, you would have to use the same STR the reporter used. The reporter already tested this & indicated that this does not reproduce on 1.4, which concludes this is a regression in the memory space.

Comment 17

[Johan Lorenzo [:jlorenzo]]

With the numbers in comment 13, we see that Homescreen was killed before the bug reproduces. So, when we go into cards views, Homescreen is launched again provoking the OOM. 

How can we prove that this regression happened in the Browser process and not in the Homescreen, then?

Comment 18

[Jason Smith [:jsmith]]

(In reply to Johan Lorenzo [:jlorenzo] from comment #17)
> With the numbers in comment 13, we see that Homescreen was killed before the
> bug reproduces. So, when we go into cards views, Homescreen is launched
> again provoking the OOM. 
> 
> How can we prove that this regression happened in the Browser process and
> not in the Homescreen, then?

The #1 we rely on for regression checking is branch checking here against a consistent STR here, which already states this does not reproduce on 1.4, but reproduces on 2.0. Can we please focus on what regressed here?

Comment 19

[Ben Francis [:benfrancis]]

Focusing on what has regressed.

Comment 20

[Jason Smith [:jsmith]]

(In reply to Ben Francis [:benfrancis] from comment #19)
> Focusing on what has regressed.

Let's be careful with the title change here - I'll add the details you included, but we need to include what is the fallout from increased memory.

Comment 21

[Ben Francis [:benfrancis]]

To repeat myself again, nothing has regressed in the browser app. Browser tab content processes (including session history) getting killed in low memory conditions is expected and correct behaviour.

The fact that you see this more often on a device with less available memory is also expected behaviour. This bug is serving no useful purpose, the useful way to track this issue is in the many existing bugs around memory usage in Gaia.

Please stop wasting engineering time and artificially raising the blocker count.

Comment 22

[Jason Smith [:jsmith]]

(In reply to Ben Francis [:benfrancis] from comment #21)
> To repeat myself again, nothing has regressed in the browser app. Browser
> tab content processes (including session history) getting killed in low
> memory conditions is expected and correct behaviour.

And this isn't right. The reporter already clearly indicated that they cannot reproduce this bug on 1.4. That's likely because there's higher memory usage from 1.4 --> 2.0.

> 
> The fact that you see this more often on a device with less available memory
> is also expected behaviour. This bug is serving no useful purpose, the
> useful way to track this issue is in the many existing bugs around memory
> usage in Gaia.

This isn't right. This reproduces on 2.0, doesn't reproduce on 1.4 due to an increase of memory usage.

> 
> Please stop wasting engineering time and artificially raising the blocker
> count.

We have a critical requirement of focusing on dropping memory usage of the phone in a low memory environment. The fact that this is a regression points to an increase of memory, which is something that could reproduce across devices. I don't think you've presented any new information here, so I'm setting the blocking flag here back, as we were given an objective at a higher-level to drop memory usage in order to meet certification requirements for 2.0.

Comment 23

[:Eli Perelman]

FxOS Perf Triage: This is a problem due to memory pressure. Since the homescreen memory usage issues tracked by Bug 1029902 are the highest priority at the moment, we want to re-test this after Bug 1029902 is resolved. For now we'll just block on that and see if this goes away when homescreen uses less memory.

Comment 24

[Kevin Grandon :kgrandon]

This needs to be resolve regardless of homescreen memory pressure. This is a race condition in the system app. The homescreen should OOM and we should be able to re-launch it.

We are going to improve the homescreen soon, but I fear that is just going to mask the real problem.

Comment 25

[Kevin Grandon :kgrandon]

(In reply to Kevin Grandon :kgrandon from comment #24)
> This needs to be resolve regardless of homescreen memory pressure. This is a
> race condition in the system app. The homescreen should OOM and we should be
> able to re-launch it.
> 
> We are going to improve the homescreen soon, but I fear that is just going
> to mask the real problem.

Sorry, this comment relates more to bug 1037627. It looks like this is clearly reproduceable in 1.4, but possibly not as likely. In any case, we should solve this independent of homescreen memory work. (It should OOM in the background and app logic should work the same way)

Comment 26

[Aus Lacroix [:aus]]

It genuinely looks like this is absolutely *not* a regression of the Browser App and should *not* be treated as such. We can block on it and as memory issues are resolved re-test, but it's illogical to pin this on an application that has nothing to do with the issue.

I firmly believe this is a generic issue. When an application is killed it does not have it's state pushed to bfcache. If it did, this would be a non-issue for *all applications*.

That being said, there's a lot of work that would be needed to ensure that we *can* push to bfcache when OOM killing.

Comment 27

[Candice Serran (:cserran)]

confirmed retesting needed

Comment 28

[Chris Kreinbring [:CKreinbring]]

The bug repros on Flame 2.1 (273 MB), Flame 2.0 (273 MB), Flame 1.4 (273 MB).

Flame 2.1 (273 MB)
Build ID: 20140721062116
Gaia: Unknown due to bug 1039739
Gecko: 0dc711216018
Platform Version: 33.0a1
Firmware Version: v122
User Agent: Mozilla/5.0 (Mobile; rv:33.0) Gecko/33.0 Firefox/33.0

Flame 2.0 (273 MB)
Build ID: 20140721000201
Gaia: 8cb1a949f2e9650bb2c5598e78a6f24a58bbaf97
Gecko: 4bd4b0ae7bbe
Platform Version: 32.0a2
Firmware Version: v122
User Agent: Mozilla/5.0 (Mobile; rv:32.0) Gecko/32.0 Firefox/32.0

Flame 1.4 (273 MB)
Build ID: 20140721000201
Gaia: 621d152f89347c79619aa909ad62cc2ac9d3ab5b
Gecko: 83b7be7fb33f
Platform Version: 30.0
Firmware Version: v122
User Agent: Mozilla/5.0 (Mobile; rv:30.0) Gecko/30.0 Firefox/30.0

Actual results: After long pressing the Home button, waiting about 30 seconds, then tapping the Browser card to return to the app, the Back button will become disabled.

--------------------------------------------------------------------------------------------------------

The bug does not repro on Flame 2.0 (512 MB)

Build ID: 20140721000201
Gaia: 8cb1a949f2e9650bb2c5598e78a6f24a58bbaf97
Gecko: 4bd4b0ae7bbe
Platform Version: 32.0a2
Firmware Version: v122
User Agent: Mozilla/5.0 (Mobile; rv:32.0) Gecko/32.0 Firefox/32.0

Actual results:  After long pressing the Home button, waiting about 30 seconds, then tapping the Browser card to return to the app, the Back button will remain enabled.

Comment 29

[Jason Smith [:jsmith]]

(In reply to Chris Kreinbring [:CKreinbring] from comment #28)
> The bug repros on Flame 2.1 (273 MB), Flame 2.0 (273 MB), Flame 1.4 (273 MB).
> 
> Flame 2.1 (273 MB)
> Build ID: 20140721062116
> Gaia: Unknown due to bug 1039739
> Gecko: 0dc711216018
> Platform Version: 33.0a1
> Firmware Version: v122
> User Agent: Mozilla/5.0 (Mobile; rv:33.0) Gecko/33.0 Firefox/33.0
> 
> Flame 2.0 (273 MB)
> Build ID: 20140721000201
> Gaia: 8cb1a949f2e9650bb2c5598e78a6f24a58bbaf97
> Gecko: 4bd4b0ae7bbe
> Platform Version: 32.0a2
> Firmware Version: v122
> User Agent: Mozilla/5.0 (Mobile; rv:32.0) Gecko/32.0 Firefox/32.0
> 
> Flame 1.4 (273 MB)
> Build ID: 20140721000201
> Gaia: 621d152f89347c79619aa909ad62cc2ac9d3ab5b
> Gecko: 83b7be7fb33f
> Platform Version: 30.0
> Firmware Version: v122
> User Agent: Mozilla/5.0 (Mobile; rv:30.0) Gecko/30.0 Firefox/30.0
> 
> Actual results: After long pressing the Home button, waiting about 30
> seconds, then tapping the Browser card to return to the app, the Back button
> will become disabled.
> 
> -----------------------------------------------------------------------------
> ---------------------------
> 
> The bug does not repro on Flame 2.0 (512 MB)
> 
> Build ID: 20140721000201
> Gaia: 8cb1a949f2e9650bb2c5598e78a6f24a58bbaf97
> Gecko: 4bd4b0ae7bbe
> Platform Version: 32.0a2
> Firmware Version: v122
> User Agent: Mozilla/5.0 (Mobile; rv:32.0) Gecko/32.0 Firefox/32.0
> 
> Actual results:  After long pressing the Home button, waiting about 30
> seconds, then tapping the Browser card to return to the app, the Back button
> will remain enabled.

Chris - I don't think that's the STR Derek used here. There's no mention of 30 seconds in his STR. Can you double check with him on what he did here?

Comment 30

[Chris Kreinbring [:CKreinbring]]

Derek and I talked about this, and we agreed that the bug is much more likely to occur if the user waits about 5 seconds before going back into the Browser app.

Comment 31

[Jason Smith [:jsmith]]

(In reply to Chris Kreinbring [:CKreinbring] from comment #30)
> Derek and I talked about this, and we agreed that the bug is much more
> likely to occur if the user waits about 5 seconds before going back into the
> Browser app.

Chris - Is the STR that Derek originally using here reproducing on 1.4 or not?

Comment 32

[Chris Kreinbring [:CKreinbring]]

Yes, I was able to repro on today's 1.4.

Comment 33

[Jason Smith [:jsmith]]

(In reply to Chris Kreinbring [:CKreinbring] from comment #32)
> Yes, I was able to repro on today's 1.4.

Ok. That clarifies this isn't a regression here, which I wish we would have determined up front here, as it caused a lot of confusion. I'm clearing flags here now that there's agreement this isn't a regression.

Comment 34

[Jason Smith [:jsmith]]

Can you also check 1.3 as well?

Comment 35

[Chris Kreinbring [:CKreinbring]]

Unable to repro on the Flame 1.3 (273 MB) base image.

Build ID: 20140616171114
Gaia: e1b7152715072d27e0880cdc6b637f82fa42bf4e
Gecko: e181a36ebafaa24e5390db9f597313406edfc794
Platform Version: 28.0
Firmware Version: v122
User Agent: Mozilla/5.0 (Mobile; rv:28.0) Gecko/28.0 Firefox/28.0

Actual result:  After long pressing the Home button, waiting for a few seconds, then tapping the Browser card to return to the app, the Back button will remain enabled.

Comment 36

[Jason Smith [:jsmith]]

Oh - well, I guess my comment above wasn't right then. Probably don't think we need to worry about this though if it reproduces on 1.4.

Comment 37

[Dave Huseby [:huseby]]

This repros on v123 OEM updated with latest v2.0 gecko+gaia.

Build ID: 20140721000201
Git commit info: 2014-07-20 19:52:30 2cb1a949
Platform Version; 32.0a2

1. flashed v123 OEM
2. used the B2G-flash-tool to update gecko+gaia to the latest v2.0 (aurora).  
3. loaded up stackexchange.com and visited the first question page.  
4. held the home button to go to the card view.
5. tapped on the browser to go back into the browser app.
6. back button goes from active to grayed out as browser app comes back into focus.

This is on a 319MB memory profile flame.

-dave

Comment 38

[Mike Lien[:mlien]]

qawanted to branch check for v2.2 and v3.0

Comment 39

[Alissa（leave from Mozilla）]

Hi mike, This issue has been successfully verified on Flame 2.2, 3.0, but it is also successfully verified on  flame 2.1, please help to check the video, thanks
Reproducing rate: 0/5
Device Flame 2.1:
Build ID               20150330161200
Gaia Revision          6f39e4e876152de1dcdcc0e7656197f22f105e4b
Gaia Date              2015-03-25 11:16:16
Gecko Revision         https://hg.mozilla.org/releases/mozilla-b2g34_v2_1/rev/275ad18f587b
Gecko Version          34.0
Device Name            flame
Firmware(Release)      4.4.2
Firmware(Incremental)  eng.cltbld.20150330.193934
Firmware Date          Mon Mar 30 19:39:44 EDT 2015
Bootloader             L1TC000118D0

Device:
Flame 2.2:
Build ID               20150330162503
Gaia Revision          cc11248ab69f13e89416c8e6bb2e184187e72088
Gaia Date              2015-03-30 22:22:58
Gecko Revision         https://hg.mozilla.org/releases/mozilla-b2g37_v2_2/rev/90a26917ee8f
Gecko Version          37.0
Device Name            flame
Firmware(Release)      4.4.2
Firmware(Incremental)  eng.cltbld.20150330.201412
Firmware Date          Mon Mar 30 20:14:21 EDT 2015
Bootloader             L1TC000118D0

Device Flame 3.0:
Build ID               20150330160204
Gaia Revision          be25b16efa19bab8d54be08f8fe45dcc93bf93d0
Gaia Date              2015-03-29 10:19:00
Gecko Revision         https://hg.mozilla.org/mozilla-central/rev/6dedce1ca673
Gecko Version          40.0a1
Device Name            flame
Firmware(Release)      4.4.2
Firmware(Incremental)  eng.cltbld.20150330.191926
Firmware Date          Mon Mar 30 19:19:35 EDT 2015
Bootloader             L1TC000118D0

Comment 40

[Alissa（leave from Mozilla）]

Attachment: VIDEO0463.3gp

Comment 41

[Mike Lien[:mlien]]

From comment 39, now this problem cannot be reproduced on v2.1, v2.2, and v3.0.

Comment 42

[Gabriele Svelto [:gsvelto] (PTO)]

I'm sorry I hadn't noticed this before because I know exactly why this is happening and in fact I'm fixing the underlying issue in bug 1142806. Long story short, when you enter the cards view all apps are set as hidden downgrading their priority to the background level. We decide to kill apps based on how much available memory we have and on how important is an app. When going from the foreground to the background the visible browser will have its priority lowered and if we're low enough on memory the LMK will kill to free more even though there would still be available memory to keep it alive.

Comment 43

[Bobby Chien]

close bug per comment 41.