Closed Bug 1117981 Opened 9 years ago Closed 9 years ago

Lockscreen doesn't show updated time after being woken up from sleep

Categories

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

Product:
Firefox OS Graveyard
Component:
Gaia::System::Lockscreen
Platform:
ARM
Gonk (Firefox OS)
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

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

Status:
VERIFIED FIXED
Milestone:
2.2 S3 (9jan)
Project Flags:
blocking-b2g 2.2+
Tracking Flags:
Tracking Status
b2g-v2.0 --- unaffected
b2g-v2.1 --- unaffected
b2g-v2.2 --- verified

People

(Reporter: pmathur, Assigned: gweng)

References

Details

(Keywords: regression, smoketest)

Attachments

(5 files, 2 obsolete files)

Lockscreen shows 5:31 pm on Sat Jan 3, 2015. Actual time is Mon Jan 5 at 12:59 pm. Settings > Date & Time shows 1:00 pm but Status bar stuck at 12:59 pm.
146.56 KB, image/jpeg
Details
adb logcat
59.39 KB, text/plain
Details
lockscreen-sync with statusbar
146.56 KB, image/png
Details
statusbar-sync with date & time
217.58 KB, image/png
Details
date & time: no automatically set switcher, although timezone is correct (automatically set via FTU + WiFi)
23.85 KB, image/png
Details 
Steps to reproduce:

1. Full flash your phone and go through the First Time Experience (FTE) wizard.
2. In Settings, go to Date & Time and uncheck "Set Automatically".
3. Set the correct timezone for your region (default is America / New York).
4. Check "Set Automatically".
5. Allow the phone to do a screen timeout.
6. Press the power button to display the lockscreen.

Expected Results
The lockscreen should show the current time.


Actual Results
The lockscreen shows the past time. (see screenshot and logcat attached)


Test Environment:
Device-Name     flame
Gaia-Rev        698e6e8a098cc060b26cd6f25171633c4c7e739d
Gecko-Rev       https://hg.mozilla.org/mozilla-central/rev/13fe5ad0364d
Build-ID        20150102010205
Version         37.0a1
FW-Release      4.4.2
FW-Incremental  eng.cltbld.20150102.043329
FW-Date         Fri Jan  2 04:33:39 EST 2015
Bootloader      L1TC00011880

Notes:
I full flashed my Flame device on Fri Jan 2, 2015 and looked at the lockscreen again on Mon Jan 5 at 12:59 pm. The time shown was 5:31 pm on Sat Jan 3, 2015. When I navigated to Settings > Date & Time, it showed the time as 1:00 pm while the Status bar at the top still showed 12:59 pm.
Status bar might be a different problem. I also saw the bug where the time on the lockscreen isn't correct but the status bar time is correct.
blocking-b2g: --- → 2.2?
Whiteboard: [systemsfe]
Whiteboard: [systemsfe]
Requesting branch checks and regression window, please.
Keywords: qawanted
I think No-Jun was seeing something like this in bug 1116672.
Flags: needinfo?(npark)
I've seen both LockScreen and Statusbar are incorrect. But it's a bit long ago.
I've fixed a bug that clock won't update after rebooting at Bug 1116091. It may be relevant (or not).
With my device:

Build ID               20150104160203
Gaia Revision          04d5b8dd414307c335aae08b71d2ba3992f3f058
Gaia Date              2015-01-06 06:32:32
Gecko Revision         https://hg.mozilla.org/mozilla-central/rev/636498d041b5
Gecko Version          37.0a1
Device Name            flame
Firmware(Release)      4.4.2
Firmware(Incremental)  65
Firmware Date          Mon Dec 15 18:51:29 CST 2014
Bootloader             L1TC000118D0

The time is totally wrong: it's 4:13PM but on statusbar and LockScreen both show 12:00. And I don't know why but I can't find the 'Set Automatically' on the Date and Time page.

I've connect to Wi-Fi during FTU, and it asked no timezone. This may make difference, so I would give it a check again.
BTW: I've one SIM card in the case. I would do some test.
Without SIM card (rebooting): it change to 9:36 (still incorrect, now it's 4:25). Both LockScreen and Statusbar are the same.
I found it's strange: I flashed my device with FTU without SIM card twice. The first time it reproduced the case, but the second time time on LockScreen & Statusbar are both correct.
I can only reproduce it with the following STR:

1. Shutdown the device and pull out the battery (this is very necessary)
2. Reboot it (and now the time is *incorrect*, no matter whether the time was correct or not)
3. Flash Gaia (make reset-gaia)
4. In FTU app try to adjust the date & time to the correct one
5. After FTU, re-lock it and the bug occurs

However, after the current minute passed, the time is correct on LockScreen. This give us a possibility of quickfix, that I may fix LockScreen bug with one patch. However, this seems relevant with battery (step 2), so I suspect that there is a bug in hardware or Gecko.
And I don't know why but on my device it never give me the 'Set Automatically' option...
OK. On v2.2 I fixed the bug with my patch. I'll write tests and wait the branch check result to see if v2.1 needs it, too.
Attached file Patch (obsolete) — 
Fixed: refresh the clock when FTU is done. Since user may change date & time in FTU app.
Attachment #8544459 - Flags: review?(timdream)
Assignee: nobody → gweng
Triage: blocking
blocking-b2g: 2.2? → 2.2+
Smoketest blocker per IRC discussion with Gregor Wagner.

NI on Mwargers, is it possible to automate this?

Link to moztrap smoke test case that was added:
https://moztrap.mozilla.org/manage/cases/?filter-id=15243
Flags: in-qa-testsuite?(martijn.martijn)
Keywords: qawanted → qaurgent, regression, regressionwindow-wanted, smoketest
QA Contact: bzumwalt
(In reply to Peter Bylenga [:PBylenga] from comment #19)
> Smoketest blocker per IRC discussion with Gregor Wagner.
> 
> NI on Mwargers, is it possible to automate this?

Yes, see bug 1118054, comment 1.
Depends on: 1118054
We are investigating this original bug (comment 0). We think the problem comes with toggling the 'Set Automatically' button and it is intermittent.

STR at comment 14 involves rebooting which makes me think it's related to this longstanding bug 1061797, so we'll skip that STR and focus on the original bug.

Brogan will post branch check result next, and will work on getting the window.
Keywords: qawanted
Issue DOES occur on Flame 2.2

Reproducing issue 100% with different repro steps. Unable to reproduce issue reliably with STR from comment 0. When performing the below steps the time in the status bar changes 2 to 3 times within a short period of time. The lockscreen time shown is incorrect and behind the time shown in the status bar.

Repro Steps:
1) Update a Flame device to BuildID: 20150106010234
2) Go through FTU not changing any settings (do not enable cell data or WiFi)
3) Navigate to Settings > Date & Time
4) Toggle off and then back on (observe status bar time)
5) Press power twice to view lock screen

Repro Rate: 5/5 (100%)

Device: Flame 2.2 Master (319mb)
BuildID: 20150106010234
Gaia: b77e0d56d197e0ee02d801a25c784130d888c9db
Gecko: 2a193b7f395c
Version: 37.0a1 (2.2 Master)
Firmware: V188-1
User Agent: Mozilla/5.0 (Mobile; rv:37.0) Gecko/37.0 Firefox/37.0


Issue does NOT reproduce in Flame 2.0 or 2.1

Before and after correcting timezone in settings, the lockscreen shows the same time as the status bar.

Device: Flame 2.0 (319mb)
BuildID: 20150106000204
Gaia: f76014fd2c7528493b90d759c68ec3070233d094
Gecko: aedeb9e38bb9
Version: 32.0 (2.0)
Firmware: V188-1
User Agent: Mozilla/5.0 (Mobile; rv:32.0) Gecko/32.0 Firefox/32.0

Device: Flame 2.1 (319mb)
BuildID: 20150106001308
Gaia: b04a8cb7b2482e0a44e6702b48c42283a00b5b1e
Gecko: 99cea2c818f6
Version: 34.0 (2.1)
Firmware: V188-1
User Agent: Mozilla/5.0 (Mobile; rv:34.0) Gecko/34.0 Firefox/34.0
QA Whiteboard: [QAnalyst-Triage?]
Flags: needinfo?(ktucker)
Keywords: qawanted
:gweng, are you able to reproduce with steps outlined in comment 22?
Flags: needinfo?(gweng)
QA Whiteboard: [QAnalyst-Triage?] → [QAnalyst-Triage+]
Flags: needinfo?(ktucker)
So I think my patch could fix one STR similar to this bug, since I can't reproduce the bug with STRs in comment 22 and comment 0. One vague thing is in comment 22 it described "Go through FTU not changing any settings", but I at least need to adjust my timezone and of course the time (which is incorrect after flashing). If I don't do that in FTU, after I change that in Date & Time in Settings, the clock on LockScreen would be correct and sync with Statusbar's.

And unfortunately even with another Flame I still can't find the Set Automatically button in Date & Time. Without that I can't follow comment 0.

BTW, a bug with 3 similar STRs (and 3 reporter report it works while others doesn't) is confused. Should I clone this bug to land my patch for my STR? Since it indeed fixed the bug with the STR I mentioned in comment 14? Or should we fork two bugs for the two STRs and land my patch for this bug?

My Flame:

Gaia-Rev        b77e0d56d197e0ee02d801a25c784130d888c9db
Gecko-Rev       https://hg.mozilla.org/mozilla-central/rev/2a193b7f395c
Build-ID        20150106010234
Version         37.0a1
Device-Name     flame
FW-Release      4.4.2
FW-Incremental  39
FW-Date         Thu Oct 16 18:19:14 CST 2014
Bootloader      L1TC00011880
Flags: needinfo?(gweng)
Repro rate dropped off further along in regression window. Will complete inbound window tomorrow morning. Leaving qaurgent and regressionwindow-wanted until then.

Last Working Central Build:
Device: Flame 2.2 Master (319MB)(Kitkat Base)(Shallow Flash)
BuildID: 20141229172835
Gaia: 322ef5116a5827a30c9a3cd9b842449a9c66a5b3
Gecko: 67872ce17918
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 Central Build:
Device: Flame 2.2 Master (319mb)(Kitkat Base)(Shallow Flash)
BuildID: 20141230130858
Gaia: 26d479f0fccb7174e06255121e4e938c1b280d67
Gecko: 1d9ecea73a1e
Version: 37.0a1 (2.2 Master)
Firmware: V188-1
User Agent: Mozilla/5.0 (Mobile; rv:37.0) Gecko/37.0 Firefox/37.0

Last Working gaia / First Broken gecko - Issue does NOT occur
Gaia: 322ef5116a5827a30c9a3cd9b842449a9c66a5b3
Gecko: 1d9ecea73a1e

First Broken gaia / Last Working gecko - Issue DOES occur
Gaia: 26d479f0fccb7174e06255121e4e938c1b280d67
Gecko: 67872ce17918

Central Push Log: 
https://github.com/mozilla-b2g/gaia/compare/322ef5116a5827a30c9a3cd9b842449a9c66a5b3...26d479f0fccb7174e06255121e4e938c1b280d67
QA Whiteboard: [QAnalyst-Triage+] → [QAnalyst-Triage?]
Flags: needinfo?(ktucker)
Attachment #8544459 - Flags: review?(timdream) → review+
B2G-Inbound Regression Window:

Last Working Inbound Build:
Device: Flame 2.2 Master (319mb)(Kitkat Base)(Shallow Flash)
BuildID: 20141229191736
Gaia: dd23a7b904dd93fdeb399b34822d389d7b3ddc3b
Gecko: 7b81a4e37e4e
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 Inbound Build:
Device: Flame 2.2 Master (319mb)(Kitkat Base)(Shallow Flash)
BuildID: 20141229193732
Gaia: 8f9412ce170991067a1a10cfaa4cba64d2034c33
Gecko: 03b905b3641d
Version: 37.0a1 (2.2)
Firmware: V188-1
User Agent: Mozilla/5.0 (Mobile; rv:37.0) Gecko/37.0 Firefox/37.0

Last Working gaia / First Broken gecko - Issue does NOT occur
Gaia: dd23a7b904dd93fdeb399b34822d389d7b3ddc3b
Gecko: 03b905b3641d

First Broken gaia / Last Working gecko - Issue DOES occur
Gaia: 8f9412ce170991067a1a10cfaa4cba64d2034c33
Gecko: 7b81a4e37e4e

Pushlog: https://github.com/mozilla-b2g/gaia/compare/dd23a7b904dd93fdeb399b34822d389d7b3ddc3b...8f9412ce170991067a1a10cfaa4cba64d2034c33
status-b2g-v2.0: --- → unaffected
status-b2g-v2.1: --- → unaffected
status-b2g-v2.2: --- → affected
Keywords: qaurgent, regressionwindow-wanted
Hey Greg, can you please take a look at this? This looks to have been caused by Bug 1116091.
QA Whiteboard: [QAnalyst-Triage?] → [QAnalyst-Triage+]
Flags: needinfo?(ktucker) → needinfo?(gweng)
Please note that I have commented I can't reproduce this with the two STRs but with mine at Comment 25. And it looks nobody answer my question at the *replied* NI about the unreproducible STRs and the missing Set Automatically function. So I can do nothing but try it again.
Flags: needinfo?(gweng)
(In reply to Greg Weng [:snowmantw][:gweng][:λ] from comment #25)
> BTW, a bug with 3 similar STRs (and 3 reporter report it works while others
> doesn't) is confused. Should I clone this bug to land my patch for my STR?
> Since it indeed fixed the bug with the STR I mentioned in comment 14? Or
> should we fork two bugs for the two STRs and land my patch for this bug?

Please use your best judgement on these questions -- you don't need approval from me or anyone to clone bugs as long as the rationale is clearly documented on Bugzilla.
Flags: needinfo?(gweng)
Also, it's entirely possible some of the STRs here are actually reproducing bug 1061797, which is out of our control.
:gweng, looking at the base image of your Flame device in comment 25, I think you need to update it first to v18D. (I've emailed you with the link where you can find this new base build.)

After you flash, please enable adb on the device and run the check_versions.sh script (part of the TW-QA tool) which should give the following output:
Gaia-Rev        79f6218c4f30c2739575c3ab800078c2cda135cb
Gecko-Rev       d9d4000dd43a3637345a41d716dc97fdd700d715
Build-ID        20141215191148
Version         32.0
Device-Name     flame
FW-Release      4.4.2
FW-Incremental  65
FW-Date         Mon Dec 15 18:51:29 CST 2014
Bootloader      L1TC000118D0

Next, please flash your phone with the latest 2.2 nightly using the TW-QA tool:
Device: flame-kk
Branch: mozilla-central
Build Type: User
Gecko/Gaia/Full: images

After you flash, you will notice that the First Time Experience (FTE) wizard no longer asks you to set the timezone. At this point, you will be able to reproduce the steps outlined in comment 22.

Then please enable adb on the device and run the check_versions.sh script (part of the TW-QA tool) which should give the following output:
Gaia-Rev        d4dac29613076bdba3cb8adc217deadb08a2ac20
Gecko-Rev       https://hg.mozilla.org/mozilla-central/rev/70de2960aa87
Build-ID        20150107160220
Version         37.0a1
Device-Name     flame
FW-Release      4.4.2
FW-Incremental  eng.cltbld.20150107.193022
FW-Date         Wed Jan  7 19:30:32 EST 2015
Bootloader      L1TC000118D0
Flags: needinfo?(npark)
I've two Flame and one is already v18D. With the Flame + latest Gaia, and the most important, the *correct* SIM card support the automatic adjusting date & time function, I've found STR at Comment 22 results in no bugs:

1) Update a Flame device to BuildID: 20150106010234  --> I flash it with the latest instead (no harm).
2) Go through FTU not changing any settings (do not enable cell data or WiFi)  --> Checked.
3) Navigate to Settings > Date & Time  --> And do nothing, according to it literally
4) Toggle off and then back on (observe status bar time)  --> Checked.
5) Press power twice to view lock screen  --> It's already *correct*

I've found after this STR, the time is automatically corrected. Both clocks on LockScreen and Statusbar shows the correct date and time. My reproducing video on YouTube is at:

http://youtu.be/M51fN09BbG8

I believe I've followed the all STR steps. Please let me know if I were wrong to reproduce the bug.

The Flame:

Build ID               20150107160220
Gaia Revision          96a47a083560c01fc37c96f0cd6dd2bd962f5e1e
Gaia Date              2015-01-08 01:58:04
Gecko Revision         https://hg.mozilla.org/mozilla-central/rev/70de2960aa87
Gecko Version          37.0a1
Device Name            flame
Firmware(Release)      4.4.2
Firmware(Incremental)  65
Firmware Date          Mon Dec 15 18:51:29 CST 2014
Bootloader             L1TC000118D0
Flags: needinfo?(gweng)
Ahh....YouTube trolls me. The correct URL of the video is

https://www.youtube.com/watch?v=9JkVPOvj7lw
OK I've got it (finally!) Thanks to everyone. The missing part is step 4 you mean to "toggle" the *Set Automatically* twice. Since it says no object so I don't get it and misunderstood you means toggle "the device". I now can take a look at the bug.
First let me clone the bug to land the patch for Comment 14. It at least works for the STR.
Blocks: 1119097
OK now I'm working on this bug.
Attached file Patch (obsolete) — 
OK. I've tested the patch on my Flame, and followed the Comment 22's STR, the symptom disappeared. I would do more test to confirm that.
Attachment #8544459 - Attachment is obsolete: true
Attachment #8545675 - Flags: review?(timdream)
I've tested again it should fix the bug. Waiting reviewing.
Comment on attachment 8545675 [details] [review]
Patch

I wonder why this is a valid fix. The life time of lock screen must have changed after v2.1, so that we need to actively monitor the `moztimechange` event.

Have we concluded the difference between STR in comment 0 and comment 22?
Attachment #8545675 - Flags: review?(timdream) → review+
I think comment 22 is a reduced version of comment 0 (step 2, 3 and 4 become the 'toggling'). So with my patch the bug disappears and I checked STR of comment 0 the patch still works (step 3 is omitted since it's already correct, so I needn't to change the timezone).

And statusbar listen to moztimechange to correct the time. So I use this to solve the bug, too.
TBPL now is with serious (and almost impossible relevant) Gij failures at keyboard app. I now take a look and would try to land the patch after fixing it.
Apologies for the missing portion of step 4 in comment 22. Should have been written as  "Toggle 'Set automatically' off and then back on (observe status bar time)"

Please note, I did not have to perform step 3 from comment 0 to get bug to occur. So it's really just a reduced steps 2 & 4.
Flags: in-qa-testsuite?(martijn.martijn) → in-qa-testsuite+
I've tested the patch on comment 40 attachment 8545675 [details] [review], the issue is still occurring after the patch.

Observed behavior: After following comment 22's STR, lockscreen time IS correct after turning on. But if I turn screen off again, and wait for a minute and turn it back on, the time does NOT update in this case.

We should back out the patch for Bug 1116091 because the root cause for bug 1116091 could actually be bug 1061797.
Flags: needinfo?(ktucker)
:timdream, this bug has prevented the smoketests from passing 100% for the last 4 days in a row. We should either fix the problem or back out the code causing the problem asap.
Flags: needinfo?(timdream)
Flags: needinfo?(ktucker)
:piwei

Sorry I don't fully understand what did you mean. It looks like:

1. It looks like the patch fixed *this* bug since you said "After following comment 22's STR, lockscreen time IS correct after turning on." -- So the patch indeed fixed the symptom described in comment 22, right?

2. And the second line: "if I turn screen off again, and wait for a minute and turn it back on, the time does NOT update in this case." -- OK I'll check this again since in my recollection I checked this once before I submitted the patch. And if I understand it correctly, this is not the bug comment 22 addressed, but a related symptom, right? (Doesn't mean it's irrelevant or unimportant. Just want to make sure the patch indeed fixed the bug).

3. [:pragmatic] Unfortunately in these 4 days we have had most of time on discussion and the reproducing tries, and the timezone issue make things looks like happened 2 days here. Of course it's exactly a serious issue, so I would back it out and reset the bug status when Gaia is open again (now tree is closed).
Flags: needinfo?(pcheng)
I had to test around it to make sure lockscreen time does get updated after doing the STR. That's the whole point to this bug, is it not?
Flags: needinfo?(pcheng)
(In reply to Greg Weng [:snowmantw][:gweng][:λ] from comment #46)
> 
> 2. And the second line: "if I turn screen off again, and wait for a minute
> and turn it back on, the time does NOT update in this case." -- OK I'll
> check this again since in my recollection I checked this once before I
> submitted the patch. And if I understand it correctly, this is not the bug
> comment 22 addressed, but a related symptom, right? (Doesn't mean it's
> irrelevant or unimportant. Just want to make sure the patch indeed fixed the
> bug).

The title of the bug is "Lockscreen doesn't show updated time after being woken up from sleep" and comment 0 points out this bug in detail, including screenshots and adb logcat. The patch needs to fix this bug.

> 3. [:pragmatic] Unfortunately in these 4 days we have had most of time on
> discussion and the reproducing tries, and the timezone issue make things
> looks like happened 2 days here. Of course it's exactly a serious issue, so
> I would back it out and reset the bug status when Gaia is open again (now
> tree is closed).

I think the code causing this bug needs to be backed out as soon as Gaia opens.
Status: NEW → ASSIGNED
Let's make smoketest happy again: 

Revert "Merge pull request #27052 from snowmantw/bug1116091-rev2" 
https://github.com/mozilla-b2g/gaia/commit/753e6b06b2d234129c3563d97050d3b59ac01d30
Comment on attachment 8545675 [details] [review]
Patch

Let reset the patching status.
Attachment #8545675 - Attachment is obsolete: true
I've re-run the STR in Comment 22 with the reverted master, and found two different results:

1. After the STR, the clocks show incorrect time, among Date & Time, LockScreen and Statusbar.

The video is here:

https://www.youtube.com/watch?v=2-yt1tPxKZw

* Before I toggled the switcher *
[Real Time] : 09:59
[Statusbar] : 09:59
[LockScreen]: --

* After the toggling *
[Real Time] : 10:00
[Statusbar] : 10:28
[LockScreen]: 10:28

2. Try it again. Now after the STR they shows the correct time.

The video is here:



I think the 1. is another bug.

And from now I would record videos run this flow every time I submit the related patch, to make sure I didn't do anything incorrectly to check and patch the bug.
Flags: needinfo?(pmathur)
Please verify for me to make sure the backout solved the issue.
:ktucker, please verify that the code backout ensures that steps in comment 0 and comment 22 no longer reproduce.
Status: ASSIGNED → RESOLVED
Closed: 9 years ago
Flags: needinfo?(pmathur) → needinfo?(ktucker)
Keywords: qawanted, verifyme
Resolution: --- → FIXED
The patch has been backed out.
Flags: needinfo?(timdream)
status-b2g-v2.2: affected → fixed
Target Milestone: --- → 2.2 S3 (9jan)
Issue still reproduces with STR's from both comment 0 as well as comment 22

STR in Comment 0: Time on status bar was 10:20, time on lockscreen was 10:13. On second attempt the time on the status bar is 10:42, but the lockscreen says 1:41. Third attempt shows 10:46 on status bar, but 1:46 on lockscreen. Issue reproduced 3/3 times.

STR in Comment 22: Had issue occur 2 out of 5 attempts. The status bar clock shows 1:24 or 1:35, the lockscreen shows 10:18 or 10:29. 

Device: Flame 2.2 Master (319mb)(Kitkat Base)(Shallow Flash)
BuildID: 20150109010206
Gaia: 5f0dd37917c4a6d8fa8724715d4d3797419f9013
Gecko: b3f84cf78dc2
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+] → [QAnalyst-Triage?]
Keywords: qawanted
Apologies, I was behind by one Gaia commit.

Issue verified fixed on Flame 2.2

Following STR from both comment 0 as well as comment 22, any combination of flashing, toggling setting time automatically, and changing time zone settings does not result in disparity between status bar time and time displayed on lockscreen

Device: Flame 2.2 Master (319mb)(Kitkat Base)(Shallow Flash)
BuildID: 20150109010206
Gaia: 2c7d14040149e1f9b1bb3972ff150be0472fa6b6
Gecko: b3f84cf78dc2
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 → VERIFIED
status-b2g-v2.2: fixed → verified
Keywords: verifyme
QA Whiteboard: [QAnalyst-Triage?] → [QAnalyst-Triage+]
Flags: needinfo?(ktucker)
This problem almost doesn't occur since the change was applied, however I have now had two experiences where the time is displayed incorrectly on the lock screen.

ACTUAL RESULTS
I turn off my Flame with the power button at top of device.
I return to the device and turn it on.
Lockscreen indicates incorrect time 12:06 (Tuesday, 20 January).
I login, now the status menu at the top shows the correct time (10:38)

EXPECTED RESULTS
I turn off my Flame with the power button at top of device.
I return to the device and turn it on.
Lockscreen indicates correct time 10:38 (Monday, 19 January).
I login, now the status menu at the top shows the correct time (10:38)

The difference is that the lockscreen now displays a seemingly random time from the following day.
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: