Closed Bug 1056379 Opened 10 years ago Closed 10 years ago

[B2G][Homescreen][Notification Bar] Time does not display in the Notification Bar when connected to a WiFi network.

Categories

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

ARM
Gonk (Firefox OS)
defect
Not set
normal

Tracking

(b2g-v2.0 unaffected, b2g-v2.1 affected)

RESOLVED FIXED
Tracking Status
b2g-v2.0 --- unaffected
b2g-v2.1 --- affected

People

(Reporter: Marty, Assigned: gmarty)

References

Details

(Keywords: regression, Whiteboard: [systemsfe])

Attachments

(8 files)

Attached file logcat-Time_Status_Bar.txt (deleted) —
Description: If the phone is connected to a WiFi network, the Notification Bar will no longer display the Time when at the homescreen. If the Notification Menu is pulled down, the Time display will return, but may disappear when returning to the homescreen again. Note: There also seems to be a similar problem where the SIM/Cell network icons are not displayed. Repro Steps: 1) Update a Flame to 20140820040203 2) Connect the device to a WiFi network in Settings 3) Navigate to the homescreen and observe the Notification Bar Actual: Time is not displayed in the Notification Bar Expected: Time is displayed in the Notification Bar Environmental Variables: Device: Flame Master Build ID: 20140820040203 Gaia: df39c463259d348396ef7f143c2c780eeb8f02d8 Gecko: ffdd1a398105 Version: 34.0a1 (Master) Firmware Version: v123 User Agent: Mozilla/5.0 (Mobile; rv:34.0) Gecko/34.0 Firefox/34.0 Keywords: Notification Bar, Status Bar, Icon, Time, Display, WiFi, Network, Priority Repro frequency: 100% Link to failed test case: https://moztrap.mozilla.org/manage/case/6784/ See attached: screenshot, logcat
Attached image Time_Status_Bar_Screenshot.png (deleted) —
This issue DOES occur on today's Tinderbox Engineering build. Time is not present in the status bar when WiFi is on. Environmental Variables: Device: Flame Tinderbox Central Engineering Build ID: 20140820071526 Gaia: 33d4b999f464fbad1c23d488da4689c5de9967ec Gecko: cbbc380f1e1c Version: 34.0a1 (Master) Firmware Version: v123 User Agent: Mozilla/5.0 (Mobile; rv:34.0) Gecko/34.0 Firefox/34.0 ------------------------------------------------------------------------ This issue does NOT occur in yesterday's Nightly build. Time displays properly in the status bar when WiFi is on. Environmental Variables: Device: Flame Nightly Master Build ID: 20140819040202 Gaia: b33b4d9558e0b9eabbfda7be23435e2b38fd40bf Gecko: 111a1da2a95d Version: 34.0a1 (Master) Firmware Version: v123 User Agent: Mozilla/5.0 (Mobile; rv:34.0) Gecko/34.0 Firefox/34.0 ------------------------------------------------------------------------ This issue does NOT occur on today's Flame Nightly 2.0 build. Time displays properly in the status bar when WiFi is on. Environmental Variables: Device: Flame Nightly 2.0 Build ID: 20140820000201 Gaia: 88db39a0826086024631049d83ae6aa397f0918d Gecko: 2092ac87eceb Version: 32.0 (2.0) Firmware Version: v123 User Agent: Mozilla/5.0 (Mobile; rv:32.0) Gecko/32.0 Firefox/32.0
QA Whiteboard: [QAnalyst-Triage?]
Flags: needinfo?(pbylenga)
[Blocking Requested - why for this release]: Bad visual regression of a core component. Requesting a window.
blocking-b2g: --- → 2.1?
QA Whiteboard: [QAnalyst-Triage?]
Flags: needinfo?(pbylenga)
QA Contact: pcheng
b2g-inbound regression window: Last Working Environmental Variables: Device: Flame BuildID: 20140818154716 Gaia: ec5baf18d4675d01ed912d57bcef0548267b43e3 Gecko: b6953906b755 Version: 34.0a1 (2.1 Master) Firmware: V123 User Agent: Mozilla/5.0 (Mobile; rv:33.0) Gecko/33.0 Firefox/33.0 First Broken Environmental Variables: Device: Flame BuildID: 20140818162717 Gaia: 6d02931dc9248edf66207066a0c01ebd3e279f8d Gecko: 99d0fb469f7f Version: 34.0a1 (2.1 Master) Firmware: V123 User Agent: Mozilla/5.0 (Mobile; rv:33.0) Gecko/33.0 Firefox/33.0 First broken gecko & last working gaia - issue does NOT repro Gaia: ec5baf18d4675d01ed912d57bcef0548267b43e3 Gecko: 99d0fb469f7f First broken gaia & last working gecko - issue DOES repro Gaia: 6d02931dc9248edf66207066a0c01ebd3e279f8d Gecko: b6953906b755 Gaia pushlog: https://github.com/mozilla-b2g/gaia/compare/ec5baf18d4675d01ed912d57bcef0548267b43e3...6d02931dc9248edf66207066a0c01ebd3e279f8d Caused by Bug 1042105.
QA Whiteboard: [QAnalyst-Triage?]
Flags: needinfo?(jmitchell)
broken by bug 1042105 ? Mike - can you take a look?
Blocks: 1042105
QA Whiteboard: [QAnalyst-Triage?] → [QAnalyst-Triage+]
Flags: needinfo?(jmitchell) → needinfo?(mhenretty)
Can we retest this now that bug 1056004 has landed? This is a mix of duplicate of bug 1056004, and working to spec. Since for most apps, the statusbar will be taken up by the rocketbar, we hide certain icons based on priority. In this case, time is less important than SIM status, and Wifi, etc. See the spec here: https://bugzilla.mozilla.org/attachment.cgi?id=8476853
Flags: needinfo?(mhenretty)
Keywords: qawanted
Whiteboard: [systemsfe]
The bug still reproduces in certain conditions: While in an app in portrait mode, time does NOT display on status bar. The bug does NOT reproduce in: While in Homescreen in Portrait mode, or while in an app in landscape mode, time DOES display on status bar.
QA Whiteboard: [QAnalyst-Triage+] → [QAnalyst-Triage?]
Flags: needinfo?(jmitchell)
Keywords: qawanted
Comment 7 was tested on: Device: Flame 2.1 Master BuildID: 20140821152716 Gaia: afcdd36f13e75adcdebe57d842a277fd587faf28 Gecko: de740a7571fb Version: 34.0a1 (2.1 Master) Firmware: V123 User Agent: Mozilla/5.0 (Mobile; rv:33.0) Gecko/33.0 Firefox/33.0
QA Whiteboard: [QAnalyst-Triage?] → [QAnalyst-Triage+]
Flags: needinfo?(jmitchell)
UX - Can you clarify if what we're seeing here is a bug or expected?
Flags: needinfo?(firefoxos-ux-bugzilla)
This is a bug. The time should be shown on the status bar.
Flags: needinfo?(firefoxos-ux-bugzilla)
Mike - See comment 10 - UX has confirmed this is a bug. Can you take a look?
Flags: needinfo?(mhenretty)
QA Whiteboard: [QAnalyst-Triage+] → [QAnalyst-Triage+][lead-review+]
(In reply to Pi Wei Cheng [:piwei] from comment #7) > The bug still reproduces in certain conditions: While in an app in portrait > mode, time does NOT display on status bar. > > The bug does NOT reproduce in: While in Homescreen in Portrait mode, or > while in an app in landscape mode, time DOES display on status bar. Can you provide a screenshot? According to the spec [1], time has a lower priority than 8 other statusbar icons, so if the sum of those 8 displayed take up the majority of the statusbar when rocketbar is minimized, then time will indeed be hidden. Let's see what icons are displayed. 1.) https://bugzilla.mozilla.org/attachment.cgi?id=8476853
Flags: needinfo?(mhenretty) → needinfo?(pcheng)
Attached image comparison screenshots (deleted) —
(In reply to Michael Henretty [:mhenretty] from comment #12) > Can you provide a screenshot? Screenshots provided. On the left is reproducing the bug - in Settings app (or any app) the time is not displayed. On the right is while at Homescreen with the same elements on status bar, time is displayed.
Flags: needinfo?(pcheng)
(In reply to Michael Henretty [:mhenretty] from comment #12) > (In reply to Pi Wei Cheng [:piwei] from comment #7) > > The bug still reproduces in certain conditions: While in an app in portrait > > mode, time does NOT display on status bar. > > > > The bug does NOT reproduce in: While in Homescreen in Portrait mode, or > > while in an app in landscape mode, time DOES display on status bar. > > Can you provide a screenshot? According to the spec [1], time has a lower > priority than 8 other statusbar icons, so if the sum of those 8 displayed > take up the majority of the statusbar when rocketbar is minimized, then time > will indeed be hidden. Let's see what icons are displayed. > > 1.) https://bugzilla.mozilla.org/attachment.cgi?id=8476853 I'm not sure I agree with the design decision here. Users have an expectation of being able to see their time. Not having this in a basic use case (e.g. the screenshot seen on the left with a DSDS device with wifi) is probably likely not going to make it through a certification, since I'm betting on the fact that operators expect time to be shown on the phone.
I've contacted Rob about this. In the specs, the time is almost always shown, with rare exception.
Flags: needinfo?(rmacdonald)
(In reply to Pi Wei Cheng [:piwei] from comment #13) > Created attachment 8477623 [details] > comparison screenshots > > (In reply to Michael Henretty [:mhenretty] from comment #12) > > Can you provide a screenshot? > > Screenshots provided. > > On the left is reproducing the bug - in Settings app (or any app) the time > is not displayed. > On the right is while at Homescreen with the same elements on status bar, > time is displayed. FWIW - looking at the screenshot here, I think the main problem I see in the current implementation is that the rocketbar search in the notification bar is taking up too much space. Why do we need half the notification bar for a search bar? Why couldn't I just use a 1/4 of the notification bar? I'm also confused why we need to show the app name in the search bar. Wouldn't it make more sense to show the word "Search?"
Hi everyone... This bug is valid. The time does have lower priority than 8 other icons, however, in this case the time should be shown. The priority in the spec is: 1) Emergency CB Location 2) SOS 3) Battery 4) Recording 5) Flight mode 6) Wi-Fi 7) SIM 1 Signal Strength (if occupied) 8) SIM 2 Signal Strength (if occupied) 9) The time In the attachment, the time should be shown. However, there are a few optimizations that need to take place to make this happen, all of which are known issues although not all have been assigned bugs as of this afternoon. These optimizations include: - adjusting the spacing of the icons to allow for a fifth slot when the input field is present. - moving the PM indicator closer to the time or eliminating am/pm entirely - eliminating the empty sim indicator (existing bug) As a result, time should be displayed in most instances. I intended to file the outstanding bugs after a review with engineering yesterday but have been working on other issues, but they will be filed for Monday morning. Best regards, Rob
Flags: needinfo?(rmacdonald)
Attached image screenshot of settings app (deleted) —
Are we still seeing this problem? on a build from today, 8/25, the time is shown even though only battery and wifi signal is present and everything else is missing. I tried this on Calendar, Settings, Email, Music, Videoand other third party apps (like notes, calculator) Gaia e424c85eda87a40c0fa64d6a779c3fa368bf770b Gecko https://hg.mozilla.org/mozilla-central/rev/daa84204a11a BuildID 20140825040204 Version 34.0a1 ro.build.version.incremental=110 ro.build.date=Fri Jun 27 15:57:58 CST 2014 B1TC00011230
Flags: needinfo?(mshuman)
Attached image StatusBar_Clock_OTA_and_Flash.png (deleted) —
We are still seeing this at a 100% repro rate when we are connected to WiFi, after both a fresh flash, and an OTA. The Time is confirmed to be missing in the Status Bar in the following locations: Calendar Settings Email Music Calculator (Marketplace App) Notes (Marketplace App) When viewing the Video app, we do not see the Status Bar at all. Environmental Variables: Device: Flame Master Build ID: 20140825040204 Gaia: e424c85eda87a40c0fa64d6a779c3fa368bf770b Gecko: daa84204a11a Version: 34.0a1 (Master) Firmware Version: v123 User Agent: Mozilla/5.0 (Mobile; rv:34.0) Gecko/34.0 Firefox/34.0
Flags: needinfo?(mshuman)
QA Whiteboard: [QAnalyst-Triage+][lead-review+] → [QAnalyst-Triage?][lead-review+]
Flags: needinfo?(pbylenga)
blocking-b2g: 2.1? → 2.1+
QA Whiteboard: [QAnalyst-Triage?][lead-review+] → [QAnalyst-Triage+][lead-review+]
Flags: needinfo?(pbylenga)
Guillaume, can you take a look here?
Assignee: nobody → gmarty
Component: Gaia::System::Window Mgmt → Gaia::System
This bug is invalid. Here's the math: On portrait, the rocket bar takes 50% of the width, so 160px are left available for the status bar on a Flame. 1) Emergency CB Location = 0px (hidden) 2) SOS = 0px (hidden) 3) Battery = 30px (including 5px for spacing) 4) Recording = 0px (hidden) 5) Flight mode = 0px (hidden) 6) Wi-Fi = 21px (including 5px for spacing) 7) SIM 1 Signal Strength (if occupied) 8) SIM 2 Signal Strength (if occupied) = 71px total (including 5px for spacing) 9) The time = 56px now (width depends on the time and the number of digits) 160 - 30 - 21 - 71 = 38px There is only 38px available so the time cannot fit in as it's bigger, so we don't show it. As Rob pointed out, the optimisations are very likely to bring the time most of the time if not all the time.
Discussed this with UX in IRC: 10:06 AM <jsmith_> robmac: So gmarty seems to think that bug 1056379 is invalid 10:07 AM <jsmith_> robmac: But that's leaving a little bit confused. I thought the intention of the design in bug 1042105 was to have the time show up in most instances (time should only not be present in a rare case), but that bug is implying it's showing up in a basic use case. What do you think we should do here? 10:08 AM <robmac> jsmith_: i’m going to have to look at the math with eric 10:09 AM <robmac> there should be an available slot for time 10:09 AM <robmac> jsmith_ plus looking at the patch last night i don’t think the optimizations are in place 10:10 AM <robmac> looking at the screen shots there should be space for an extra slot 10:12 AM <robmac> jsmith_ there are also two potential optimizations around the clock that may help - one is removing the space between the time and AM/PM. the other option (more drastic) is removing am/pm entirely. one of those should give us enough space.
(In reply to Guillaume Marty [:gmarty] from comment #21) > This bug is invalid. Here's the math: > On portrait, the rocket bar takes 50% of the width, so 160px are left > available for the status bar on a Flame. > 1) Emergency CB Location = 0px (hidden) > 2) SOS = 0px (hidden) > 3) Battery = 30px (including 5px for spacing) > 4) Recording = 0px (hidden) > 5) Flight mode = 0px (hidden) > 6) Wi-Fi = 21px (including 5px for spacing) > 7) SIM 1 Signal Strength (if occupied) > 8) SIM 2 Signal Strength (if occupied) = 71px total (including 5px for > spacing) > 9) The time = 56px now (width depends on the time and the number of digits) > > 160 - 30 - 21 - 71 = 38px > There is only 38px available so the time cannot fit in as it's bigger, so we > don't show it. > > As Rob pointed out, the optimisations are very likely to bring the time most > of the time if not all the time. Hey Guillaume, Is this following the spec I created? https://mozilla.box.com/s/ekd7l17a1rxs2su8lgry Cause I left more then 160px. There should be approx 169.3px or space (254 px on flame). With almost 10 px of extra space we should be able to fix the time. There's been a bug opened to address the incorrect RB sizing. Hopefully it lands soon...
Flags: needinfo?(gmarty)
Depends on: 1056965
Eric, your updated spec has not landed yet. Those changes are in bug 1056965, and we just got the r+ for that but the tree is closed and we need to fix a unit test. Once that lands, this bug will be fixed. I can verify that by applying the patch and taking the following screenshot.
Flags: needinfo?(gmarty)
Removing smoketest keyword per conversation in 8-27 meeting with Gregor, tchung, jsmith and pbylenga.
Keywords: smoketest
(In reply to Marcia Knous [:marcia - use needinfo] from comment #25) > Removing smoketest keyword per conversation in 8-27 meeting with Gregor, > tchung, jsmith and pbylenga. We came to agreement that we need to fix this for 2.1 as a blocker, but we don't have to block smoketests mainly because the time can still be seen at certain parts of the phone.
As Eric pointed out, when Bug 1054778 lands, we'll get more space in the status bar for time.
Now that bug 1056965 has landed, can we retest this? I think we are good now.
Keywords: qawanted
Comment on attachment 8480020 [details] [screenshot] statusbar with bug applied This attachment appears to have fixed the time issue, although I'm still not seeing it in my build. Eric will need to review it against the visual spec, the space between the 2:03 and "PM" still seems slightly wide. I'll ping Michael on IRC this afternoon to confirm I have the right patch on my device.
Attached image Screenshot of fixed issue (deleted) —
Verified with original STR that when connected to Wifi, time is now displayed when in an app. Attaching a screenshot. Tested on: Device: Flame BuildID: 20140828132252 Gaia: 007f3c50cf69f044628a23c2376c6d88aa45f617 Gecko: d697d649c765 Version: 34.0a1 (2.1 Master) Firmware: V123 User Agent: Mozilla/5.0 (Mobile; rv:33.0) Gecko/33.0 Firefox/33.0
QA Whiteboard: [QAnalyst-Triage+][lead-review+] → [QAnalyst-Triage?][lead-review+]
Flags: needinfo?(jmitchell)
Keywords: qawanted
Looks like this is good to close!
QA Whiteboard: [QAnalyst-Triage?][lead-review+] → [QAnalyst-Triage+][lead-review+]
Flags: needinfo?(jmitchell)
Status: NEW → RESOLVED
blocking-b2g: 2.1+ → ---
Closed: 10 years ago
Resolution: --- → FIXED
Attached image Sept 2 2014 Settings Screenshot (deleted) —
Adding screen shot to show status as of Sept 2. This bug still seems to apply as the gap between the search input field and the SIM1 signal strength indicator should be great enough to show the time. NI'ing Guillaume and Eric to discuss.
Flags: needinfo?(gmarty)
Flags: needinfo?(epang)
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Depends on: 1062278
Thanks Rob for digging this out. Looking into it allowed me to find Bug 1062278 (a fix is pending r? at the moment). With this fix applied, the time hardly shows up (if at all). But the math is correct, we're only short of the a few pixels to show the time (~7 pixels best case). I need to look into what the impact of Bug 1056969 can be (very likely to make it worse). But as said above, Bug 1052465 and Bug 1054778 are very likely to fix this time issue.
Flags: needinfo?(gmarty)
(In reply to Guillaume Marty [:gmarty] from comment #33) > Thanks Rob for digging this out. > Looking into it allowed me to find Bug 1062278 (a fix is pending r? at the > moment). > > With this fix applied, the time hardly shows up (if at all). But the math is > correct, we're only short of the a few pixels to show the time (~7 pixels > best case). > > I need to look into what the impact of Bug 1056969 can be (very likely to > make it worse). > But as said above, Bug 1052465 and Bug 1054778 are very likely to fix this > time issue. Hi Guillaume, is this with the current RB size? Or the size it should be, cause in the screen shot it still seems to be using 50% of the status bar which is incorrect. Also, is the time that doesn't fit with AM/PM or without? Collapsed/Expanded RB width/height: https://bugzilla.mozilla.org/show_bug.cgi?id=1054778 Kevin, do you know what's happening with the bug 1054778? It directly effects this bug because of the spacing for status bar icons.
Flags: needinfo?(kgrandon)
Flags: needinfo?(gmarty)
Flags: needinfo?(epang)
Rob - Can we breakout a different bug for the issue you've found? The original STR as written seems fixed, but I think we've found a different bug here with the same feature.
Flags: needinfo?(rmacdonald)
(In reply to Eric Pang [:epang] from comment #34) > Kevin, do you know what's happening with the bug 1054778? It directly > effects this bug because of the spacing for status bar icons. We are still looking at that one, but it turns out that it may be quite risky for 2.1. Hopefully we'll have an update at the end of this week. There's a lot more we can do here still. According to comment 21 the sim slot should only have a higher priority than the time if occupied. Why is the second sim slot displayed, and where is the bug to address this?
Flags: needinfo?(kgrandon)
Let's see if bug 1052465 and bug 1057977 give us the space we need here, since reducing the width of RB in 2.1 (bug 1054778) sounds much riskier.
Depends on: 1052465, 1057977
Flags: needinfo?(gmarty)
(In reply to Jason Smith [:jsmith] from comment #35) > Rob - Can we breakout a different bug for the issue you've found? The > original STR as written seems fixed, but I think we've found a different bug > here with the same feature. It seems that we've covered this issue under multiple existing bugs so I'll defer to Guillaume as to whether we should create a separate bug. Guillaume, is it safe to close this one?
Flags: needinfo?(rmacdonald) → needinfo?(gmarty)
Yes, Rob, I think it's safe to close this one and follow up with the depending bugs.
Status: REOPENED → RESOLVED
Closed: 10 years ago10 years ago
Flags: needinfo?(gmarty)
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: