[Search] Rocketbar gets stuck in active position on apps in background after browser LMK

RESOLVED DUPLICATE of bug 1120541

Status

defect
RESOLVED DUPLICATE of bug 1120541
5 years ago
4 years ago

People

(Reporter: jlee, Assigned: cwiiis)

Tracking

({regression})

unspecified
2.2 S3 (9jan)
ARM
Gonk (Firefox OS)
Dependency tree / graph

Firefox Tracking Flags

(blocking-b2g:2.2+, b2g-v2.0 unaffected, b2g-v2.1 unaffected, b2g-v2.2 verified, b2g-master verified)

Details

(Whiteboard: [2.2-exploratory-2][systemsfe], )

Attachments

(6 attachments)

Description:
After browser LMK, Rocketbar will get stuck in active/down position on all open apps in background. Back buttons are covered in some apps.
   
Repro Steps:

*Have these apps opened in background - Contacts (open specific contact), Email (compose message screen), Marketplace (go to any app page), Settings (open any specific setting)

1) Update a Flame device to BuildID: 20141222040204
Open Browser > Go to site that will cause low memory kill in browser (for ex, www.dragonage.com) 
Go to Settings > Observe Rocketbar (and Back button)
Go to Contacts > Observe Rocketbar (and Back button)
Go to Marketplace > Observe Rocketbar (and Back button)
Go to Email > Observe Rocketbar (and Back button)
  
Actual:
With apps opened in background and a browser LMK occuring, Rocketbar gets stuck in active position on background apps. 
  
Expected: 
With apps opened in background and a browser LMK occuring, Rocketbar does not get stuck in active position on background apps. Rocketbar works as intended.
  
Environmental Variables:
Device: Flame 2.2 Master (319mb)(Kitkat Base)(Full Flash)
BuildID: 20141222040204
Gaia: ca6e91e09ef3ab417a0f6b6d6668d43597d85700
Gecko: b915a50bc6be
Gonk: e5c6b275d77ca95fb0f2051c3d2242e6e0d0e442
Version: 37.0a1 (2.2 Master)
Firmware: V188-1
User Agent: Mozilla/5.0 (Mobile; rv:37.0) Gecko/37.0 Firefox/37.0
  
Notes: Apps must be restarted to have properly functioning Rocketbar.
  
Repro frequency: 4/4, 100%
See attached: video clip (http://youtu.be/GHCfJV3OMcQ), logcat (rocketbarstuck_logcat.txt), screenshot (composeemail.PNG, contacts.PNG, marketplace.PNG, settings.PNG)
Posted image composeemail
Flags: needinfo?(dharris)
Posted image contacts
Posted image marketplace
Posted image settings
Issue does NOT occur on Flame 2.1 or Flame 2.0.

With apps opened in background and a browser LMK occuring, Rocketbar does not get stuck in active position on background apps. Rocketbar works as intended.

Device: Flame 2.1 (319mb)(Kitkat Base)(Full Flash)
Build ID: 20141222001236
Gaia: 6af3d029bae3a14f400fec0926f0f8ad7b579b4b
Gecko: 39eaa987093b
Gonk: e5c6b275d77ca95fb0f2051c3d2242e6e0d0e442
Version: 34.0 (2.1)
Firmware Version: v188-1
User Agent: Mozilla/5.0 (Mobile; rv:34.0) Gecko/34.0 Firefox/34.0

Device: Flame 2.0 (319mb)(Kitkat Base)(Full Flash)
Build ID: 20141222000200
Gaia: ce83ea7b8e3fa2d1c3fd771fc22b654c18b3c381
Gecko: 752225b5d185
Gonk: e5c6b275d77ca95fb0f2051c3d2242e6e0d0e442
Version: 32.0 (2.0)
Firmware Version: v188-1
User Agent: Mozilla/5.0 (Mobile; rv:32.0) Gecko/32.0 Firefox/32.0
QA Whiteboard: [QAnalyst-Triage?]
I'm currently having trouble reproducing this on master. Any chance we can get a regression window here?

Also a video of the state *before* the bug happening and going into the state of the bug could be really useful.
qawanted to get a video requested at comment 6.
Keywords: qawanted
Video doing the STR (demonstrating each app working properly before browser LMK, and bug reproducing in each app after browser lmk):

https://www.youtube.com/watch?v=tsVo7Y4tkIk

Repro rate is 3/3 on latest master, with factory resetting the phone via Settings between each attempt.

Tested on:
Device: Flame 2.2 Master (full flash, 319MB mem)
Build ID: 20141229071436
Gaia: ea413f7cdec44db0e241c0820e0aca2daeac436c
Gecko: a4a5d4fb5e2e
Gonk: a814b2e2dfdda7140cb3a357617dc4fbb1435e76
Version: 37.0a1 (2.2 Master)
Firmware Version: v188-1
User Agent: Mozilla/5.0 (Mobile; rv:37.0) Gecko/37.0 Firefox/37.0
Flags: needinfo?(jmitchell)
Keywords: qawanted
QA Whiteboard: [QAnalyst-Triage?]
Flags: needinfo?(jmitchell)
Flags: needinfo?(dharris)
Regression of a core feature breaking functionality.
blocking-b2g: --- → 2.2?
QA Contact: pcheng
b2g-inbound regression window:

Last Working Environmental Variables:
Device: Flame
BuildID: 20141218025302
Gaia: c7ee7755e0fd14c74595b2ae02f148e17be69777
Gecko: ddcd1f3ff8a9
Version: 37.0a1 (2.2 Master)
Firmware: V188-1
User Agent: Mozilla/5.0 (Mobile; rv:37.0) Gecko/37.0 Firefox/37.0

First Broken Environmental Variables:
Device: Flame
BuildID: 20141218040802
Gaia: a1c514b158cc25a1ffa2fa78177b78277243b068
Gecko: 325f5e922768
Version: 37.0a1 (2.2 Master)
Firmware: V188-1
User Agent: Mozilla/5.0 (Mobile; rv:37.0) Gecko/37.0 Firefox/37.0

First Broken Gaia & Last Working Gecko - issue DOES repro
Gaia: a1c514b158cc25a1ffa2fa78177b78277243b068
Gecko: ddcd1f3ff8a9

First Broken Gecko & Last Working Gaia - issue does NOT repro
Gaia: c7ee7755e0fd14c74595b2ae02f148e17be69777
Gecko: 325f5e922768

Gaia pushlog:
https://github.com/mozilla-b2g/gaia/compare/c7ee7755e0fd14c74595b2ae02f148e17be69777...a1c514b158cc25a1ffa2fa78177b78277243b068

Caused by Bug 1112594.
QA Whiteboard: [QAnalyst-Triage?]
Flags: needinfo?(jmercado)
Caused by Bug 1112594 - Chris can you take a look?
Blocks: 1112594
QA Whiteboard: [QAnalyst-Triage?] → [QAnalyst-Triage+]
Flags: needinfo?(jmercado) → needinfo?(chrislord.net)
Whiteboard: [2.2-exploratory-2] → [2.2-exploratory-2][systemsfe]
Regression
blocking-b2g: 2.2? → 2.2+
Assignee: nobody → chrislord.net
Status: NEW → ASSIGNED
Flags: needinfo?(chrislord.net)
Fix and test.
Attachment #8545993 - Flags: review?(alive)
Attachment #8545993 - Flags: review?(alive) → review+
Merged: https://github.com/mozilla-b2g/gaia/commit/f2b884cad54428b9f3ee1ee35e445034db590f0a
Status: ASSIGNED → RESOLVED
Closed: 5 years ago
Resolution: --- → FIXED
Target Milestone: --- → 2.2 S3 (9jan)
This issue is still occurring on Flame 2.2 and 3.0. We've been constantly getting this bug using different steps, but the original STR still reproduces this bug solidly.

Bug 1120541 had been filed to further track this bug.

Device: Flame 2.2
BuildID: 20150123002505
Gaia: 237008137f6d72b9cad25ff4faff14ff2c40ac63
Gecko: be24dd482a83
Gonk: e7c90613521145db090dd24147afd5ceb5703190
Version: 37.0a2 (2.2) 
Firmware Version: v18D-1
User Agent: Mozilla/5.0 (Mobile; rv:37.0) Gecko/37.0 Firefox/37.0

Device: Flame 3.0
BuildID: 20150123010227
Gaia: cba2f0bf49b882e0044c3cc583de8fcf83d2ffa4
Gecko: 494632b9afed
Gonk: e7c90613521145db090dd24147afd5ceb5703190
Version: 38.0a1 (3.0) 
Firmware Version: v18D-1
User Agent: Mozilla/5.0 (Mobile; rv:38.0) Gecko/38.0 Firefox/38.0
QA Whiteboard: [QAnalyst-Triage+] → [QAnalyst-Triage?][failed-verification]
Flags: needinfo?(ktucker)
See Also: → 1120541
QA Whiteboard: [QAnalyst-Triage?][failed-verification] → [QAnalyst-Triage+][failed-verification]
Flags: needinfo?(ktucker)
Is this bug still occurring?  I tried but can't.
Flags: needinfo?(pcheng)
This bug has been verified fixed in Bug 1120541. This bug failed verification on comment 15, and because by the time we had time to verify it, it had been over 10 days since the patch landed and our general rule was to handle the bug in a separate bug after 10 days if it was still occurring.

In short, this bug is the same as bug 1120541 and it has been verified fixed.
Flags: needinfo?(pcheng)
Thanks, Pi Wei.
Keywords: verifyme
Resolution: FIXED → DUPLICATE
Duplicate of bug: 1120541
QA Whiteboard: [QAnalyst-Triage+][failed-verification] → [QAnalyst-Triage+]
You need to log in before you can comment on or make changes to this bug.