Closed
Bug 1057589
Opened 10 years ago
Closed 9 years ago
[System] Time is not preserved after restarting device.
Categories
(Firefox OS Graveyard :: Vendcom, defect)
Tracking
(blocking-b2g:2.0+, b2g-v2.0 verified, b2g-v2.1 verified)
People
(Reporter: Marty, Assigned: aus)
References
Details
(Keywords: regression, smoketest, Whiteboard: [POVB])
Description:
After long-pressing the power button, and selecting 'Restart,' the time has been changed to be inaccurate by several minutes or hours. Usually, it is fast by 10-15 minutes, but can also be off by several (3 to 8) hours if the device is restarted multiple times.
Note: In the Date and Time settings, the date and time zone is still accurate.
This occurs both with and without a SIM inserted, and with or without a WiFi connection.
Repro Steps:
1) Update a Flame to 20140822000206
2) Note the Time displayed on the phone.
3) Long-press the power button, and select 'Restart'
4) Note the time on the lock screen when the device powers back up
Actual:
The time is significantly inaccurate
Expected:
The time is still accurate.
Environmental Variables:
Device: Flame 2.0
Build ID: 20140822000206
Gaia: 64b0c0ae60fdeac953a7e2a3c368d124bf848477
Gecko: 5075528d7241
Version: 32.0 (2.0)
Firmware Version: v123
User Agent: Mozilla/5.0 (Mobile; rv:32.0) Gecko/32.0 Firefox/32.0
Notes: This issue occurs on both 512MB and 319MB memory
Repro frequency: >75%
Link to failed test case:
--------------------------------------------------------------------------------------
This issue DOES occur on Flame 2.1
Time is inaccurate after a device restart.
Environmental Variables:
Device: Flame Master
Build ID: 20140822040202
Gaia: afcdd36f13e75adcdebe57d842a277fd587faf28
Gecko: 0b9dd32d1e16
Version: 34.0a1 (Master)
Firmware Version: v123
User Agent: Mozilla/5.0 (Mobile; rv:34.0) Gecko/34.0 Firefox/34.0
Reporter | ||
Updated•10 years ago
|
QA Whiteboard: [QAnalyst-Triage?]
Flags: needinfo?(pbylenga)
Comment 1•10 years ago
|
||
[Blocking Requested - why for this release]:
Smoketest Regression of a core function of the phone.
Requesting a window.
blocking-b2g: --- → 2.0?
QA Whiteboard: [QAnalyst-Triage?]
Flags: needinfo?(pbylenga)
Updated•10 years ago
|
QA Contact: rpribble
When this happens does the time change to the correct time immediately after you unlock the device? If so I've been seeing this on my Nexus 5 for months.
Reporter | ||
Comment 3•10 years ago
|
||
We have seen this occur where the inaccurate time persists indefinitely while the device is on, and then the problem can compound after subsequent restarts. We have also seen the issue where the time corrects itself about 30 seconds after boot-up, but this does not happen every time. We see that the time does NOT recover after start up about 70% of the time.
QA Whiteboard: [QAnalyst-Triage?]
Flags: needinfo?(pbylenga)
Comment 4•10 years ago
|
||
Let's have the window focus on the issue where the inaccurate time persists indefinitely on the homescreen.
QA Whiteboard: [QAnalyst-Triage?]
Flags: needinfo?(pbylenga)
Comment 5•10 years ago
|
||
Updating with correct repro steps that I've been informed of and am now following.
Repro Steps:
1) Update a Flame to 20140822000206
2) Settings > Date & Time > Set the correct time zone
3) Note the Time displayed on the phone.
4) Long-press the power button, and select 'Restart'
5) Note the time on the lock screen when the device powers back up
Restarting regression window check.
Assignee | ||
Comment 6•10 years ago
|
||
I believe this is the same issue as reported in bug 1048154.
Status: NEW → RESOLVED
Closed: 10 years ago
Resolution: --- → DUPLICATE
Updated•10 years ago
|
Keywords: qaurgent,
regressionwindow-wanted
Updated•10 years ago
|
blocking-b2g: 2.0? → ---
Comment 7•10 years ago
|
||
Aus & I discussed this offline - we think the bugs are related here, but they might not be exact dupes, since the STR involved in each bug is different. As a result, we're deciding to reopen the bug & mark the other bug as a see also.
Comment 8•10 years ago
|
||
[Blocking Requested - why for this release]:
Smoketest blocking regression.
blocking-b2g: --- → 2.0?
Updated•10 years ago
|
blocking-b2g: 2.0? → 2.0+
Comment 9•10 years ago
|
||
aus, quick check to see if you investigating this as well ?
Flags: needinfo?(aus)
Assignee | ||
Comment 10•10 years ago
|
||
Indeed, I believe this is probably the same root cause as bug 1048154 so taking this one on as well.
Assignee: nobody → aus
Flags: needinfo?(aus)
Whiteboard: [systemsfe]
Target Milestone: --- → 2.1 S3 (29aug)
Assignee | ||
Updated•10 years ago
|
Status: REOPENED → ASSIGNED
Comment 11•10 years ago
|
||
Flagging qawanted to see if this reproduces with the kitkat base image.
Keywords: regressionwindow-wanted → qawanted
Comment 12•10 years ago
|
||
I could not reproduce this issue on the v165 KitKat Base image.
Comment 13•10 years ago
|
||
(In reply to Ghislain Aus Lacroix [:aus] from comment #10)
> Indeed, I believe this is probably the same root cause as bug 1048154 so
> taking this one on as well.
Given comment 12's testing I think you are definitely right. This is a vendor bug, so I'll kick the other bug out to vendcom.
Status: ASSIGNED → RESOLVED
Closed: 10 years ago → 10 years ago
Resolution: --- → DUPLICATE
Updated•10 years ago
|
QA Whiteboard: [QAnalyst-Triage?] → [QAnalyst-Triage+]
Flags: needinfo?(jmitchell)
Comment 14•10 years ago
|
||
We found a vendor workaround, so moving this to fixed.
Component: Gaia::System → Vendcom
Resolution: DUPLICATE → FIXED
Whiteboard: [systemsfe] → [POVB]
Updated•10 years ago
|
Reporter | ||
Comment 15•10 years ago
|
||
Verified Fixed. Issue no longer occurs when using the provided workaround script.
Time is preserved after restarting the device.
Environmental Variables:
Device: Flame 2.1
Build ID: 20140905000202
Gaia: 95e9b099aa89ded133e44014dd40b19dc0193c01
Gecko: 92a6bbdfd945
Version: 34.0a2 (2.1)
Firmware Version: v123
User Agent: Mozilla/5.0 (Mobile; rv:34.0) Gecko/34.0 Firefox/34.0
Environmental Variables:
Device: Flame 2.0
Build ID: 20140905000204
Gaia: 4627014cc5c5eeec894183866d4c57291302f8b8
Gecko: 2fae20afe1fa
Version: 32.0 (2.0)
Firmware Version: v123
User Agent: Mozilla/5.0 (Mobile; rv:32.0) Gecko/32.0 Firefox/32.0
Status: RESOLVED → VERIFIED
QA Whiteboard: [QAnalyst-Triage+] → [QAnalyst-Triage?]
Flags: needinfo?(pbylenga)
Updated•10 years ago
|
QA Whiteboard: [QAnalyst-Triage?] → [QAnalyst-Triage+]
Flags: needinfo?(pbylenga)
Comment 16•10 years ago
|
||
(In reply to Jason Smith [:jsmith] from comment #14)
> We found a vendor workaround, so moving this to fixed.
(In reply to Martin Shuman [:Marty] from comment #15)
> Verified Fixed. Issue no longer occurs when using the provided workaround
> script.
> Time is preserved after restarting the device.
Please can we have more details as to what the fix is, and how we get it on our Flames?
I, for one, haven't been dogfooding for several months, because of not having the correct date/time - and this also potentially resolves a few other bugs, but I can't test until I know how...
Comment 17•10 years ago
|
||
See https://intranet.mozilla.org/QA/B2G_Tips_and_Tricks#latest_OEM_JellyBean_Base_Image:_v123_.2B_fonts
Flags: needinfo?(mshuman)
Flags: needinfo?(jsmith)
Updated•10 years ago
|
Comment 18•9 years ago
|
||
I am seeing this bug again in my Flame with 3.0. base image v18D and the 20150624160209 build. I can't update to a newer build because I'm not receiving OTA updates since then.
Status: VERIFIED → REOPENED
Resolution: FIXED → ---
Comment 19•9 years ago
|
||
Same as the other, please don't re-open old bugs (especially verified fixed) but file new ones.
Status: REOPENED → RESOLVED
Closed: 10 years ago → 9 years ago
Resolution: --- → FIXED
Updated•9 years ago
|
Status: RESOLVED → VERIFIED
Comment 20•9 years ago
|
||
I'm sorry for that, I didn't know.
You need to log in
before you can comment on or make changes to this bug.
Description
•