Closed Bug 1108152 Opened 10 years ago Closed 10 years ago

Status bar is not visible on call screen when initiating a call

Categories

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

ARM
Gonk (Firefox OS)
defect
Not set
normal

Tracking

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

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

People

(Reporter: pcheng, Assigned: gmarty)

References

Details

(Keywords: regression, Whiteboard: [planned-sprint c=3][systemsfe])

Attachments

(5 files)

Attached file logcat on Flame 2.2
Description: The status bar is blank on the call screen when initiating a call on the Flame. STR: 1) Go into Phone app 2) Dial out any number and observe the call screen Expected: Status bar is visible on call screen Actual: Status bar is NOT visible. Status bar re-appears after going to Homescreen while in a call. Repro rate: 5/5 Notes: 1) This issue does NOT occur when receiving a call on DUT 2) Attaching a logcat 3) Video URL: http://youtu.be/JAD95n85pso Tested on: Device: Flame 2.2 Master (319MB mem, shallow flash) BuildID: 20141205040650 Gaia: 529c5fcd234ffd108b57629673ca97c2ef73376d Gecko: 18188c19a3c3 Version: 37.0a1 (2.2 Master) Firmware: V188-1 User Agent: Mozilla/5.0 (Mobile; rv:37.0) Gecko/37.0 Firefox/37.0
QA Whiteboard: [QAnalyst-Triage?]
Flags: needinfo?(jmitchell)
QA-Wanted for Branch Check
QA Whiteboard: [QAnalyst-Triage?]
Flags: needinfo?(jmitchell)
Keywords: qawanted
This issue occurs on Flame 2.1. Status bar is not visible when making a phone call. Device: Flame 2.1 BuildID: 20141205113151 Gaia: f5d9fac361d1f0a0fcc3c4234e003330f486278b Gecko: e3f2852e3297 Version: 34.0 (2.1) Firmware: V188-1 User Agent: Mozilla/5.0 (Mobile; rv:34.0) Gecko/34.0 Firefox/34.0 ---------- This issue does NOT occur on Flame 2.0. Status bar is displayed when calling out. Device: Flame 2.0 BuildID: 20141204171150 Gaia: 856863962362030174bae4e03d59c3ebbc182473 Gecko: e40fe21e37f1 Version: 32.0 (2.0) Firmware: V188-1 User Agent: Mozilla/5.0 (Mobile; rv:32.0) Gecko/32.0 Firefox/32.0
QA Whiteboard: [QAnalyst-Triage?]
Flags: needinfo?(jmitchell)
Keywords: qawantedregression
nomming for 2.2 - regression, broken expected functionality
blocking-b2g: --- → 2.2?
QA Whiteboard: [QAnalyst-Triage?]
Flags: needinfo?(jmitchell)
QA Contact: pcheng
I don't see the issue on this 2.1 build: Gaia-Rev 81160ad79e5b4c21967418dd63f1a1d08d77924e Gecko-Rev https://hg.mozilla.org/releases/mozilla-b2g34_v2_1/rev/3572aa3e6766 Build-ID 20141115161200 Version 34.0 Device-Name flame FW-Release 4.4.2 FW-Incremental 39 FW-Date Thu Oct 16 18:19:14 CST 2014 Bootloader L1TC00011880 [Blocking Requested - why for this release]: Visible regression that happened in 2.1.
blocking-b2g: 2.2? → 2.1?
Triage: Visible regression on the dialer
blocking-b2g: 2.1? → 2.1+
Assignee: nobody → gsvelto
Whiteboard: [planned-sprint c=3]
Target Milestone: --- → 2.2 S2 (19dec)
b2g-inbound regression window: Last Working Environmental Variables: Device: Flame BuildID: 20141121050316 Gaia: 05d80f0af85c690e098828ed3e548b144afd904b Gecko: 7e086b657030 Version: 36.0a1 (2.2 Master) Firmware: V188-1 User Agent: Mozilla/5.0 (Mobile; rv:36.0) Gecko/36.0 Firefox/36.0 First Broken Environmental Variables: Device: Flame BuildID: 20141121060312 Gaia: 012a9d7a77942f3cf267b60c6a2c756c2b8bfea0 Gecko: e8ed47c494f5 Version: 36.0a1 (2.2 Master) Firmware: V188-1 User Agent: Mozilla/5.0 (Mobile; rv:36.0) Gecko/36.0 Firefox/36.0 First Broken Gaia & Last Working Gecko - issue DOES repro Gaia: 012a9d7a77942f3cf267b60c6a2c756c2b8bfea0 Gecko: 7e086b657030 First Broken Gecko & Last Working Gaia - issue does NOT repro Gaia: 05d80f0af85c690e098828ed3e548b144afd904b Gecko: e8ed47c494f5 Gaia pushlog: https://github.com/mozilla-b2g/gaia/compare/05d80f0af85c690e098828ed3e548b144afd904b...012a9d7a77942f3cf267b60c6a2c756c2b8bfea0 Caused by Bug 1095142.
QA Whiteboard: [QAnalyst-Triage?]
Flags: needinfo?(jmitchell)
QA Whiteboard: [QAnalyst-Triage?] → [QAnalyst-Triage+]
Flags: needinfo?(jmitchell)
QA Contact: pcheng
Can you take a look at it Guillaume?
Component: Gaia::Dialer → Gaia::System::Window Mgmt
Flags: needinfo?(gmarty)
Whiteboard: [planned-sprint c=3] → [planned-sprint c=3][systemsfe]
It looks like a dupe of Bug 1107355 and will be fixed there.
Status: NEW → RESOLVED
Closed: 10 years ago
Flags: needinfo?(gmarty)
Resolution: --- → DUPLICATE
Bug 1107355 has been verified fixed (and I personally checked that it's indeed fixed) but this bug 1108152 is still occurring on latest master. Re-opening bug. :gmarty please take a look. Device: Flame 2.2 Master (shallow flash, 512MB mem) BuildID: 20141217035735 Gaia: d22dfece04fc00457e8369c660c11f945b088d2f Gecko: cb8ad2251c09 Version: 37.0a1 (2.2 Master) Firmware: V188-1 User Agent: Mozilla/5.0 (Mobile; rv:37.0) Gecko/37.0 Firefox/37.0
Status: RESOLVED → REOPENED
Flags: needinfo?(gmarty)
Resolution: DUPLICATE → ---
blocking-b2g: 2.1+ → 2.2?
Guillaume, please take a look here.
Assignee: gsvelto → gmarty
blocking-b2g: 2.2? → 2.2+
Component: Gaia::System::Window Mgmt → Gaia::System
The callscreen is an attention window and so far, the rule has been attention window shouldn't have a visible status bar. Carrie, I think you are in charge of the dialer UX. Can you tell us if the status bar is supposed to be visible when a phone call is made or not? FYI, the status bar is not visible when a phone call is received.
Flags: needinfo?(gmarty) → needinfo?(cawang)
Target Milestone: 2.2 S2 (19dec) → 2.2 S3 (9jan)
Hi, I wonder if the call screen is the only case that uses attention window? I think it should be a full-screen window which covers the whole status bar or just displaying the status bar as in general APPs. I'd suggest the later proposal and the status bar should be always displayed even when the call is answered. Thanks! ni? Harly who works in the framework team to keep an eye on this issue.
Flags: needinfo?(cawang) → needinfo?(hhsu)
Due to consistency concerns, the UX framework team has previously decided to display status bar on all dialogs which includes attention window. If there are no technical feasibility concerns, I would suggest that status bar with all the indicator icons and "Search the web" be displayed on top of call screen. Thanks
Flags: needinfo?(hhsu)
Harly, your comment confuses me a little. I thought we must never show the status bar on attention windows. Their goal is to ask for immediate action from the user and prevent her from escaping to the Settings app from the utility tray for example. So far, all the attention windows have never been displayed the status bar and showing them would require a massive change. Can you please confirm that all attention windows need the status bar? If so, can you post a link to the new spec? Thanks :-)
Flags: needinfo?(hhsu)
Guillaume, sorry for the confusion. What I meant was that like any other screens in Firefox OS, developers can choose to display the status bar or not. If they choose to display, they should display all the indicator icons and "Search the web". However, if they choose not to display, like Gallery or Camera app, users still have the option to slide from the top edge of the screen to reveal the status bar. What I saw currently in our call screen is that there is just a black bar with no indicator, that's why I suggested that to display the indicator icons. Nevertheless, if call screen is intended to focus user's attention and do not wish to display the status bar, it is also OK to do so. I will leave the decision to Carrie who has more knowledge of user's intention in dialer.
Flags: needinfo?(hhsu)
Hi, I'd say we need to think about a use case that when users pick up a call, they might check the current time or battery life. The indicators are very useful rather than distracting in this scenario. So I'd still recommend to keep them for call screen (if we don't need to remove it). Thanks!
After taking this discussion offline with Carrie, we decided we need consistancy on incoming and outgoing calls and display the status bar in both cases. The issue is caused by the class `maximized` on the status bar element. Depending on whether it is set at the time of an incoming call, the status bar is displayed or not,
Attached file Github PR
Etienne, I hope this patch makes it clearer. I wonder if a cleaner way would be to alter the appChrome object of the attention window so that `useLightTheming()` returns false and `isMaximized()` true.
Attachment #8555286 - Flags: feedback?(etienne)
Comment on attachment 8555286 [details] [review] Github PR Small comment on github, I hope we'll have an integration test for the review round :)
Attachment #8555286 - Flags: feedback?(etienne)
Comment on attachment 8555286 [details] [review] Github PR Thanks Etienne for your feedback. How does it look now?
Attachment #8555286 - Flags: review?(etienne)
Comment on attachment 8555286 [details] [review] Github PR Looking good :)
Attachment #8555286 - Flags: review?(etienne) → review+
Status: REOPENED → RESOLVED
Closed: 10 years ago10 years ago
Resolution: --- → FIXED
Please request Gaia v2.2 approval on this when you get a chance.
Flags: needinfo?(gmarty)
Target Milestone: 2.2 S3 (9jan) → 2.2 S5 (6feb)
Comment on attachment 8555286 [details] [review] Github PR [Approval Request Comment] [Bug caused by] (feature/regressing bug #): Status bar and utility tray [User impact] if declined: The minimised status bar doesn't update anymore under some circumstances [Testing completed]: Fully unit tested, but manual testing is required [Risk to taking this patch] (and alternatives if risky): Low as tested [String changes made]: None
Flags: needinfo?(gmarty)
Attachment #8555286 - Flags: approval-gaia-v2.2?(bbajaj)
Ooops, sorry ignore the request above. Here's the correct one. [Approval Request Comment] [Bug caused by] (feature/regressing bug #): Status bar [User impact] if declined: The status bar is not always displayed in a consistent way on attention windows [Testing completed]: Unit tested, but manual testing is required [Risk to taking this patch] (and alternatives if risky): Low as tested [String changes made]: None
Attachment #8555286 - Flags: approval-gaia-v2.2?(bbajaj) → approval-gaia-v2.2+
Attached video verify_v3.0.MP4
This issue has been verified pass on Flame 3.0, the status bar is visible when initiating a call. STR: 1) Go into Phone app. 2) Dial out any number and observe the call screen. **Status bar is visible on call screen Rate:0/5 See attachment:verify_v3.0.MP4 Flame 3.0 build: Gaia-Rev 9d2378a9ef092ab1fc15c3a9f7fc4171aab59d57 Gecko-Rev https://hg.mozilla.org/mozilla-central/rev/6bfc0e1c4b29 Build-ID 20150129010239 Version 38.0a1 Device-Name flame FW-Release 4.4.2 FW-Incremental eng.cltbld.20150129.043711 FW-Date Thu Jan 29 04:37:21 EST 2015 Bootloader L1TC000118D0
QA Whiteboard: [QAnalyst-Triage+] → [QAnalyst-Triage+], [MGSEI-Triage+]
Attached video verify_v2.2.MP4
This issue has been verified successfully on Flame v2.2, the status bar is visible when initiating a call. STR: 1) Go into Phone app. 2) Dial out any number and observe the call screen. **Status bar is visible on call screen Rate:0/5 See attachment:verify_v2.2.MP4 Flame 2.2 build: Gaia-Rev d6141fa3208f224393269e17c39d1fe53b7e6a05 Gecko-Rev https://hg.mozilla.org/releases/mozilla-b2g37_v2_2/rev/f7414413e3a5 Build-ID 20150201002504 Version 37.0a2 Device-Name flame FW-Release 4.4.2 FW-Incremental eng.cltbld.20150201.043120 FW-Date Sun Feb 1 04:31:31 EST 2015 Bootloader L1TC000118D0
Kevin, do we want this for v2.1?
Flags: needinfo?(khu)
As triage. plus it.
blocking-b2g: 2.2+ → 2.1+
Flags: needinfo?(khu)
Please nominate this patch for Gaia v2.1 approval when you get a chance.
Flags: needinfo?(gmarty)
See Also: → 1052795
Comment on attachment 8555286 [details] [review] Github PR [Approval Request Comment] [Bug caused by] (feature/regressing bug #): Status bar [User impact] if declined: The status bar is not always displayed in a consistent way on attention windows. [Testing completed]: Unit tested, but manual testing is required. Already uplifted to v2.2. [Risk to taking this patch] (and alternatives if risky): Low as tested. [String changes made]: None
Flags: needinfo?(gmarty)
Attachment #8555286 - Flags: approval-gaia-v2.1?(bbajaj)
Attachment #8555286 - Flags: approval-gaia-v2.1?(bbajaj) → approval-gaia-v2.1+
This issue has re-occurred on 3.0 and 2.2. I've filed bug 1159885 for follow up.
This Problem is verified as pass on latest build of Flame 2.1 & 2.1s(512mb)by the STR in comment 0. Actual result: Status bar is visible on call screen. Rate: 0/10 See attachment: Flame2.1s_verify_video.3gp Device information: Flame v2.1 (Pass) Build ID 20150614001205 Gaia Revision f8b848c82d1ed589f7a1eb5cc099830c867ff1d4 Gaia Date 2015-06-08 09:48:23 Gecko Revision https://hg.mozilla.org/releases/mozilla-b2g34_v2_1/rev/7d767fc15126 Gecko Version 34.0 Device Name flame Firmware(Release) 4.4.2 Firmware(Incremental) eng.cltbld.20150614.033810 Firmware Date Sun Jun 14 03:38:22 EDT 2015 Bootloader L1TC000118D0 Flame v2.1s(512mb) (Pass) Build ID 20150614001204 Gaia Revision 90463896d22b564fdd3202a97ff941e6cdc502ae Gaia Date 2015-06-08 09:48:45 Gecko Revision https://hg.mozilla.org/releases/mozilla-b2g34_v2_1s/rev/1ead146c2edf Gecko Version 34.0 Device Name scx15_sp7715ea Firmware(Release) 4.4.2 Firmware(Incremental) 122 Firmware Date Thu Feb 5 12:42:58 CST 2015
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: