Closed Bug 1154635 Opened 5 years ago Closed 5 years ago
notificationbar differ between in app and homescreen
Flame b2g 188.8.131.52 - prerelease build 20150414002504 steps -open a app like telegram -look at the time in the bar at the top of the screen -pull down the notification screen - look at the time there result it is not the same time expected the same time
See the screenshots i took a few weeks ago right after each other, i still exist in the build of yesterday
There was something like bug 1107441 about this. This happens with the automatic date&time setting set? Does it matter which app you open (telegram)?
yes automatic time an does not matter witch app, the screenshot i made are with the emailapp. It looks like the bar shown in the app is not refreshing. also i.e if you turn off wifi the wifi symbol goes a way in the notification screen but not in the bar inside a app (just test it again while i was in the time settings)
Seems like the status bar still has some refresh bugs.
Guillaume can you take a here?
Assignee: nobody → gmarty
blocking-b2g: --- → 2.2?
I can't reproduce on the latest master. Tim, can you give more details about how to reproduce? Is it happening right away after booting? If no, how long after restart? Is it triggered by a particular event? I need anything really that can help me to pinpoint the issue.
I can confirm I saw some similar stuff happenning within several apps, and not only with time but also wifi, for instance. That was on master with a build which was roughly a week old (~april 10th).
Do we already have a logging mechanism in place?
blocking-b2g: 2.2? → 2.2+
Not yet, I put it on hold while Bug 1139470 got fixed. It is tracked on Bug 1144126. I'll resume working on if we can't get STR here.
I did a ota to build 20150416002504. Opened telegram wait for a few minutes and then compared the time in the app with the notificationscreen. It appears that the bar inside the app was frozen, even when i go ta a other app (mail) the time is not changing Restart Opened mail wait a few minutes and the same result. Even now (15 min later) the time show in the apps (mail, systemsettings, openwapp) stays of 15 min ago. The only thing moving in the bar is de indicator of datatransfer, if i turn off wifi that symbol does not go away It is even worser then when i first noticed it, first it reset when leave a app now it freeze
I just noticed that the time is now just 1 min behind so it refresh at some time.
I cannot reproduce this issue with master & 2.2 pvt build. @Tim, what was your previous version before ota? I noticed that Nexus 5 has similar issue with the older base image (android 5.0). * My test env ** 2.2 Build ID 20150420162501 Gaia Revision 828dd03a0e3b140d74b2e49355197df4d91d9227 Gaia Date 2015-04-20 18:28:39 Gecko Revision https://hg.mozilla.org/releases/mozilla-b2g37_v2_2/rev/36f72a3efb9b Gecko Version 37.0 Device Name flame Firmware(Release) 4.4.2 Firmware(Incremental) eng.cltbld.20150420.200111 Firmware Date Mon Apr 20 20:01:22 EDT 2015 Bootloader L1TC000118D0 ** master Build ID 20150417010203 Gaia Revision 3cd0a9facce26c2acc7be3755a17131a6358e33f Gaia Date 2015-04-16 16:33:22 Gecko Revision https://hg.mozilla.org/mozilla-central/rev/51e3cb11a258 Gecko Version 40.0a1 Device Name flame Firmware(Release) 4.4.2 Firmware(Incremental) eng.cltbld.20150417.043717 Firmware Date Fri Apr 17 04:37:26 EDT 2015 Bootloader L1TC000118D0
My baseimage is; Base image v18D (http://cds.w5v8t3u9.hwcdn.net/v18D.zip) and i am don't know witch build was the latest used for a shallowflash before the first OTA arrived ( i can check later because it is still on the desktop at my office)
i used to download the builds from https://ftp.mozilla.org/pub/mozilla.org/b2g/nightly/latest-mozilla-b2g37_v2_2-flame-kk/
Let's get the logging landed in Bug 1144126, and then see if Tim can get us a logcat since we are having trouble reproducing.
I have several thoughts here. 1 - I think my comment in bug 1139470 comment 15 still applies. I don't know if in this case the value is < 0 or > 0, but still a value < 0 should not happen. 2 - I think it's now clearly proved that the counter is highly unreliable. Tel lme if I'm wrong here: the "freeze" of the statusbar should not last more than 1sec. OK, let's say 2sec. How about introducing a timer that forces the resume after 2 sec, if it didn't happen yet? Belts and suspenders.
I worked on a fix for Bug 1154800. Though that bug is very specific, the patch is likely to fix some of the status bar issues we have. I would wait a few days before resuming work on the event logger. Also, Julien, these solutions seem really hackish and I'd rather work on the root cause than trying to fix the symptoms. If we don't, we may miss bigger issue affecting other part of the code. Let's do something like this as a last resort.
What seems hackish to me is the current fragile way of pausing/resuming using a counter. And I think the various similar bugs are all grist to the mill. Maybe it's time to revisit this unreliable logic. Really, I think it's good enough to have a 2sec timer to resume the update (pauseUpdate would cancelTimeout existing timeouts). There is no need to be more precise than this. We don't care if the update could have been resumed after 500ms rather than 2sec. And at least this logic would be rock solid.
Can QA reverify this issue on the latest build?
I cannot reproduce this bug on today's 3.0 nightly. I used email app for ~30 minutes, and a mix between other apps such as Settings, Phone, Gallery, Messages, Camera. I also tried to update icons on status bar by turning on/off wifi, data connection, NFC, bluetooth, and status bar icons and clock always match with utility tray's. Device: Flame 3.0 Master (full flashed 319MB KK) BuildID: 20150429010205 Gaia: 6e35b0948c42a4398b8a5916015de167121683a1 Gecko: 1ad65cbeb2f4 Gonk: b83fc73de7b64594cd74b33e498bf08332b5d87b Version: 40.0a1 (3.0 Master) Firmware Version: v18D-1 User Agent: Mozilla/5.0 (Mobile; rv:40.0) Gecko/40.0 Firefox/40.0 Leaving qawanted for others to attempt.
I was also unable to reproduce this issue when I updated OTA to the latest 2.2. I followed the repro steps from Comment 11 with and without 1 minute screen timeout, and changed wi-fi, airplane mode, Bluetooth, and data settings. The status bar seemed to displayed correct icons and time. [Before OTA] Environmental Variables: Device: Flame 2.2 Build ID: 20150428002500 Gaia: 9f6b1b9082662ba2c14168fc66bb02b4df3141e5 Gecko: e79c19bf19bf Gonk: ebad7da532429a6f5efadc00bf6ad8a41288a429 Version: 37.0 (2.2) Firmware Version: v18D-1 User Agent: Mozilla/5.0 (Mobile; rv:37.0) Gecko/37.0 Firefox/37.0 [After OTA] Environmental Variables: Device: Flame 2.2 Build ID: 20150429002501 Gaia: 1b7aa7e60788668ed09abf76022dfa231dbe88d4 Gecko: d38ff4717f39 Gonk: ebad7da532429a6f5efadc00bf6ad8a41288a429 Version: 37.0 (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?]
Tim, can you verify that this has been resolved on the latest build? We are unable to reproduce this issue and I want to confirm that you are unable to as well.
QA Whiteboard: [QAnalyst-Triage?]
Flags: needinfo?(ktucker) → needinfo?(bugzilla)
It looks like it is resolved. i can't reproduce it anymore
Status: NEW → RESOLVED
Closed: 5 years ago
Resolution: --- → WORKSFORME
QA Whiteboard: [QAnalyst-Triage?]
QA Whiteboard: [QAnalyst-Triage?] → [QAnalyst-Triage+]
You need to log in before you can comment on or make changes to this bug.