Closed Bug 1120541 Opened 9 years ago Closed 9 years ago

Rocketbar appears instead of app icons near the app header

Categories

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

x86
macOS
defect
Not set
normal

Tracking

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

VERIFIED FIXED
2.2 S5 (6feb)
blocking-b2g 2.2+
Tracking Status
b2g-v2.1 --- unaffected
b2g-v2.2 --- verified
b2g-master --- verified

People

(Reporter: martijn.martijn, Assigned: alive)

References

Details

(Keywords: qablocker, regression, Whiteboard: [systemsfe])

Attachments

(2 files)

Attached image Screenshot of bug
I think this is a pretty recent regression. This is with base image v18D-1 on the Flame:

Gaia-Rev        f5e481d4caf9ffa561720a6fc9cf521a28bd8439
Gecko-Rev       https://hg.mozilla.org/mozilla-central/rev/bb8d6034f5f2
Build-ID        20150112010228
Version         37.0a1
Device-Name     flame
FW-Release      4.4.2
FW-Incremental  75
FW-Date         Tue Jan  6 12:24:47 CST 2015
Bootloader      L1TC100118D0


Steps to reproduce:
- Open Usage app
- Tap on home button to go back to the Homescreen app
- Open Browser app
- Long tap on home button to pen Cards View app
- From Cards View, tap on the Usage app card

Expected result:
- Usage app appears like it was before

Actual result:
- Usage app appears, but on the place where the title and gear icon should be, the "search the web" input is there (see screenshot)
I can reproduce the same issue with the contacts App. Changing component to system.
Component: Gaia::Cost Control → Gaia::System
I produced a solid STR for producing this issue within E-Mail: Bug 1125408.

This 'Search the Web' issue doesn't transition between applications after performing the STR for the aforementioned bug, but it does linger within E-Mail until the app is closed and relaunched. I attached a logcat (as well as a video demonstrating how to produce the issue) in the bug. Posting this here in the hopes that the logcat/steps may reveal an underlying cause for producing the issue globally.
Nominating to block, this breaks functionality of many apps that have buttons near the header (example: email).
blocking-b2g: --- → 2.2?
Summary: "search the web" input is there were the title and gear icon should be with the Usage app, after switching back from the browser → Rocketbar appears instead of app icons near the app header
Can we get a branch check and regression window if needed?
Keywords: qawanted
Whiteboard: [systemsfe]
This is basically the same as bug 1115030. The fix for bug 1115030 never really fixed the bug. By the time we had time to verify it, it had been sitting there as fixed for over 10 days and we have a policy of not re-opening bugs fixed for longer than 10 days that's why we decided to track this bug here instead of re-opening 1115030.

The window and brach checking results are still valid in bug 1115030.
QA Whiteboard: [QAnalyst-Triage?]
Flags: needinfo?(ktucker)
Keywords: qawanted
QA Whiteboard: [QAnalyst-Triage?] → [QAnalyst-Triage+]
Flags: needinfo?(ktucker)
Gaia-Rev        46b590648007d51a0406b21b1d6f98eba8e3898e
Gecko-Rev       https://hg.mozilla.org/releases/mozilla-b2g37_v2_2/rev/b03afde7e699
Build-ID        20150128162504
Version         37.0a2
Device-Name     flame
FW-Release      4.4.2
FW-Incremental  eng.cltbld.20150128.201416
FW-Date         Wed Jan 28 20:14:27 EST 2015
Bootloader      L1TC100118D0

After opening many different kinds of apps and play around with it, the rocket bar would stay on the top of app. It's kind of a similar bug of bug 1125235. I don't really know if it is the same since the screenshots showed some difference.

It can be reproduced in all apps as far as you play with it long enough.
Blocks: MTBF-B2G
Hi! Ken,

Could your team help to look at this case? Thanks

--
Keven
Flags: needinfo?(kchang)
confirmed regression and broken functionality
blocking-b2g: 2.2? → 2.2+
The STR in comment #0 show the expected behaviour for me, possible dupe of bug 1115030?

n?reporter to see if this still occurs.
Flags: needinfo?(martijn.martijn)
(In reply to Chris Lord [:cwiiis] from comment #12)
> The STR in comment #0 show the expected behaviour for me, possible dupe of
> bug 1115030?
> 
> n?reporter to see if this still occurs.

It still occurs for me, using:
Gaia-Rev        ae5a1580da948c3b9f93528146b007fc4f6a712b
Gecko-Rev       https://hg.mozilla.org/mozilla-central/rev/ae5d04409cd9
Build-ID        20150203055658
Version         38.0a1

It didn't happen directly this time. I had to go through the wizard of the Usage app first and then switch back and forth between browser and Usage app a couple of times.
Flags: needinfo?(martijn.martijn)
This regression window is correct. I validated it with my steps. 

Steps:
1. Open Contacts, Messaging and Dialer.
2. On the homescreen, open task manager by holding down the home button.
3. Scroll through the 3 open apps while in card view.
4. Tap on one of the 3 apps to open it.
5. Go back into card view by holding down the home button.
5. Scroll through the 3 apps in task manager again and tap on another app to open it. 
6. Keep repeating step 3-5 until encountering the issue.
-------------------------------------------------------

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.

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

This is a dupe of bug 1115030 but that one says it has been resolved as fixed. 

This issue is hindering QA's testing. We run into this issue constantly throughout the day. This is open on the latest Flame 3.0 and Flame 2.2 

Chris is there anyway that we can get this fixed?
Flags: needinfo?(chrislord.net)
Assignee: nobody → alive
Comment on attachment 8558905 [details] [review]
[PullReq] alivedise:bugzilla/1120541/fatal-error-title-max to mozilla-b2g:master

We should not maximize title on fatal error.
Attachment #8558905 - Flags: review?(etienne)
STR to reproduce:
* Open dialer, go to homescreen
* adb shell kill {{DIALER PID}}
* Open dialer again
Clearing my needinfo, Alive has taken and fixed it (thanks :))
Flags: needinfo?(chrislord.net)
Comment on attachment 8558905 [details] [review]
[PullReq] alivedise:bugzilla/1120541/fatal-error-title-max to mozilla-b2g:master

Looking good!
Just forwarding to Chris who already commented on the tests.
Attachment #8558905 - Flags: review?(etienne) → review?(chrislord.net)
Comment on attachment 8558905 [details] [review]
[PullReq] alivedise:bugzilla/1120541/fatal-error-title-max to mozilla-b2g:master

r+ assuming the removal of the 'non-fatal' bit - I don't like creating a new event type when it's not necessary.

If you feel we must fill in the type, it should at least be more explicitly from Gaia and not from Gecko (so something like 'gaia-delayed-error').

Ideally, we'd save the error type or detail object when we receive it so we can pass the correct value. If we ever move error handling into the system app (which I think we should, eventually), we would need to do this anyway.
Attachment #8558905 - Flags: review?(chrislord.net) → review+
Alive is working on this bug.
Flags: needinfo?(kchang)
(In reply to Chris Lord [:cwiiis] from comment #20)
> Comment on attachment 8558905 [details] [review]
> [PullReq] alivedise:bugzilla/1120541/fatal-error-title-max to
> mozilla-b2g:master
> 
> r+ assuming the removal of the 'non-fatal' bit - I don't like creating a new
> event type when it's not necessary.
> 
> If you feel we must fill in the type, it should at least be more explicitly
> from Gaia and not from Gecko (so something like 'gaia-delayed-error').
> 
> Ideally, we'd save the error type or detail object when we receive it so we
> can pass the correct value. If we ever move error handling into the system
> app (which I think we should, eventually), we would need to do this anyway.

Web error handling was in system app long time before but moved back to gecko (I think it's Vivien's idea.)
I don't think we will move it back so I am not going to store the event detail.

Will go for the 'gaia-delayed-error' first. Thanks!
https://github.com/mozilla-b2g/gaia/commit/d932a55670e207de28d341368b7b92498e131683

Finally decided to keep the type as undefined.
Status: NEW → RESOLVED
Closed: 9 years ago
Resolution: --- → FIXED
Comment on attachment 8558905 [details] [review]
[PullReq] alivedise:bugzilla/1120541/fatal-error-title-max to mozilla-b2g:master

[Approval Request Comment]
[Bug caused by] (feature/regressing bug #):
Regression from bug 1112594 
[User impact] if declined:
The user will not able to interact with the top of the app if it's ever killed at background.
[Testing completed]: Y
[Risk to taking this patch] (and alternatives if risky):
The way to fix it is adding an additional check if there error is a fatal one (OOM killed) to show the search title. Don't think it's risky.
[String changes made]: NaN
Attachment #8558905 - Flags: approval-gaia-v2.2?
Alive, you steps to reproduce in comment 17, how do you adb shell kill {{DIALER PID}}? I can't seem to find the dialer app at all, when I do adb shell ps.
Btw, is this something that possibly can be reproduced on b2g desktop? I don't think I was able to.
Flags: needinfo?(alive)
Depends on: 1130064
(In reply to Martijn Wargers [:mwargers] (QA) from comment #25)
> Alive, you steps to reproduce in comment 17, how do you adb shell kill
> {{DIALER PID}}? I can't seem to find the dialer app at all, when I do adb
> shell ps.

You can use any other apps such as messages.

> Btw, is this something that possibly can be reproduced on b2g desktop? I
> don't think I was able to.

I don't think so.
Flags: needinfo?(alive)
Attachment #8558905 - Flags: approval-gaia-v2.2? → approval-gaia-v2.2+
This issue is verified fixed on Flame 3.0

The rocketbar no longer appears in an expanded view in the app header of apps when transitioning between each other after 20 attempts

Environmental Variables:
Device: Flame 3.0 (319mb)(Kitkat)(Full Flash)
Build ID: 20150206010204
Gaia: 94af4b42d2ace6c9f38f31de77240604fac68af1
Gecko: 7c5f187b65bf
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

A patch is not uplifted to 2.2 yet and the flag is still set to affected. Not verifying 2.2 as fixed yet.
Status: RESOLVED → VERIFIED
QA Whiteboard: [QAnalyst-Triage+] → [QAnalyst-Triage?]
Flags: needinfo?(pbylenga)
QA Whiteboard: [QAnalyst-Triage?] → [QAnalyst-Triage+]
Flags: needinfo?(pbylenga)
Keywords: qawanted, verifyme
QA Whiteboard: [QAnalyst-Triage+]
QA Contact: pcheng
This issue has been verified fixed on latest 2.2 tinderbox engineering build. I tried with steps from:

Bug 1115030 comment 0 - Repro rate 0 out of 6 attempts
This bug comment 14 - Repro rate 0 out of 5 attempts of repeating steps 3 to 5
This bug comment 17 - Repro rate 0 out of 5 attempts

In all instances the app displayed correctly upon re-opening

Device: Flame 2.2 (full flash, 319MB mem)
BuildID: 20150206135524
Gaia: e827781324cbde91d2434b388f5dead3303a85ee
Gecko: 418673bfce1f
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
QA Whiteboard: [QAnalyst-Triage?]
Flags: needinfo?(ktucker)
Keywords: qawanted, verifyme
QA Whiteboard: [QAnalyst-Triage?] → [QAnalyst-Triage+]
Flags: needinfo?(ktucker)
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: