Closed
Bug 1061797
Opened 10 years ago
Closed 10 years ago
[Flame][Clock Time] After restarting the phone, the time and date displayed are wrong until there is a connection to the Internet
Categories
(Firefox OS Graveyard :: Vendcom, defect)
Tracking
(blocking-b2g:2.2+, b2g-v1.4 affected, b2g-v2.0 affected, b2g-v2.1 affected, b2g-v2.2 affected)
RESOLVED
DUPLICATE
of bug 1110010
blocking-b2g | 2.2+ |
People
(Reporter: rdaub, Unassigned)
References
Details
(Keywords: dogfood, Whiteboard: [SUMO-b2g], POVB)
Attachments
(1 file)
36.91 KB,
image/png
|
Details |
ENVIRONMENT:
Device: Flame
Version: 2.0.0.0-prerelease
Build ID: 20140831000202
STEPS TO REPRODUCE:
1. Activate Airplane Mode to disable data and wi-fi connections.
2. Restart the device.
EXPECTED RESULTS:
The phone should remember the time and date from before - in my test, it should show September 2 @ 9:45am.
ACTUAL RESULTS:
The phone shows the wrong date and time - August 31 @ 10:43pm.
Once I deactivate Airplane mode, and the phone has data, the time and date are displayed correctly again.
Please let me know if there is any information I could provide to help with the investigation and troubleshooting of this issue.
Thanks!!
- Ralph
Reporter | ||
Updated•10 years ago
|
Whiteboard: [SUMO-b2g]
Updated•10 years ago
|
QA Contact: ckreinbring
Comment 2•10 years ago
|
||
The bug repros on Flame 2.2, Flame 2.1, Flame 2.0, Flame 1.4, and Open C 2.2
Actual result: Restarting the device after enabling airplane mode will cause the device to not show the proper time until the airplane mode is disabled.
Flame 2.2
BuildID: 20140903062451
Gaia: 52670853c17fc0d3d33065c667c0ce124c93b98f
Gecko: 5e9826980be5
Platform Version: 35.0a1
Firmware Version: V123
User Agent: Mozilla/5.0 (Mobile; rv:35.0) Gecko/35.0 Firefox/35.0
Flame 2.1
BuildID: 20140903085050
Gaia: fbb297c39aab5f17b179533d2a9a6c5166b2c197
Gecko: 31dad821234e
Platform Version: 34.0a2
Firmware Version: V123
User Agent: Mozilla/5.0 (Mobile; rv:33.0) Gecko/33.0 Firefox/33.0
Flame 2.0
BuildID: 20140903060552
Gaia: d056733f8a7a1a152f5458b323f092c47dbffa48
Gecko: 5137a70489dd
Platform Version: 32.0
Firmware Version: V123
User Agent: Mozilla/5.0 (Mobile; rv:32.0) Gecko/32.0 Firefox/32.0
Flame 1.4
BuildID: 20140903033752
Gaia: 2ee5b00bfbb8a67a967094804390b4afce8ecf54
Gecko: f5a75c0dd74e
Platform Version: 30.0
Firmware Version: V123
User Agent: Mozilla/5.0 (Mobile; rv:30.0) Gecko/30.0 Firefox/30.0
Open C 2.2
BuildID: 20140903062451
Gaia: 52670853c17fc0d3d33065c667c0ce124c93b98f
Gecko: 5e9826980be5
Platform Version: 35.0a1
Firmware Version: P821A10v1.0.0B06_LOG_DL
User Agent: Mozilla/5.0 (Mobile; rv:35.0) Gecko/35.0 Firefox/35.0
QA Whiteboard: [QAnalyst-Triage?]
status-b2g-v1.4:
--- → affected
status-b2g-v2.0:
--- → affected
status-b2g-v2.1:
--- → affected
status-b2g-v2.2:
--- → affected
Flags: needinfo?(jmitchell)
Keywords: qawanted
Comment 3•10 years ago
|
||
[Blocking Requested - why for this release]: not a regression but telling the time (properly) is one of the most quintessential tasks of any device.
blocking-b2g: --- → 2.0?
QA Whiteboard: [QAnalyst-Triage?] → [QAnalyst-Triage+]
Flags: needinfo?(jmitchell)
Comment 4•10 years ago
|
||
I also encounter this issue in 2.1 also.
STR:
1. restart device with wifi on and 3G on
2. after b2g is ready. the time is wrong. Can't find "Set automatically" switch.
3. Need to disable wifi and access web via 3G. Then date and time is correct.
Comment 5•10 years ago
|
||
QA Wanted to see if this happens with 2.0 with the KK image.
Keywords: qawanted
Updated•10 years ago
|
QA Contact: ckreinbring → aalldredge
Updated•10 years ago
|
QA Whiteboard: [QAnalyst-Triage+] → [QAnalyst-Triage+][lead-review+]
Comment 6•10 years ago
|
||
I was unable to repro this issue in 2.0 on the KK base. When I restarted the phone with airplane mode on the time was off by a maximum of 5 minutes. I never observed the time being different by a manner of hours.
Environmental Variables:
Device: Flame 2.0
BuildID: 20140908131505
Gaia: 59a670d40ad7f5966ec7fafcab0f05009bea97ab
Gecko: de70f9a40834
Version: 32.0 (2.0)
Firmware: V165
User Agent: Mozilla/5.0 (Mobile; rv:32.0) Gecko/32.0 Firefox/32.0
Repro rate:
0/5
QA Whiteboard: [QAnalyst-Triage+][lead-review+] → [QAnalyst-Triage?][lead-review+]
Flags: needinfo?(jmitchell)
Keywords: qawanted
Updated•10 years ago
|
QA Whiteboard: [QAnalyst-Triage?][lead-review+] → [QAnalyst-Triage+][lead-review+]
Flags: needinfo?(jmitchell)
Comment 7•10 years ago
|
||
This is a JB issue and given the 2.0 is shipping on KK not blocking here and moving this out of blocking queue.
blocking-b2g: 2.0? → ---
Updated•10 years ago
|
Component: Gaia → Vendcom
Whiteboard: [SUMO-b2g] → [SUMO-b2g], POVB
Reporter | ||
Comment 8•10 years ago
|
||
Hi,
I was able to replicate this issue on a Flame device with KK base image and Master branch flashed. (KK Base image v180 + v2.2 flashed user build).
Is QA able to verify whether this is indeed still replicating on KK-based images? Thanks in advance for the help!
- Ralph
Flags: needinfo?(jmitchell)
Flags: needinfo?(bbajaj)
Comment 9•10 years ago
|
||
QA-Wanted to re-check KK Branch
QA Whiteboard: [QAnalyst-Triage+][lead-review+] → [lead-review+]
Flags: needinfo?(jmitchell)
Keywords: qawanted
QA Contact: aalldredge
Comment 10•10 years ago
|
||
I'm able to reproduce the issue on Flame 2.2 master, Flame 2.1, and Flame 2.0.
Observed behavior on Flame 2.1: After rebooting the phone with airplane mode turned on, the phone is in a date 3 days earlier and also in different time before rebooting. The date&time adjust itself to the correct ones when I disable airplane mode (data doesn't need to be turned on, and I didn't have wifi connection either).
Observed behavior on Flame 2.0 and Flame 2.2: After rebooting with airplane mode turned on, the time is about 6 hours earlier than it should but it's on the same date.
Device: Flame 2.2 Master (shallow/full flash, 319MB mem)
BuildID: 20141013042753
Gaia: 2a536e4df82410178d8440cc710d8f838a95a0b9
Gecko: 71edd80236b2
Version: 35.0a1 (2.2 Master)
Firmware: V180
User Agent: Mozilla/5.0 (Mobile; rv:35.0) Gecko/35.0 Firefox/35.0
Device: Flame 2.1 (shallow flash, 319MB mem)
BuildID: 20141010110704
Gaia: d18e130216cd3960cd327179364d9f71e42debda
Gecko: 610ee0e6a776
Version: 34.0a2 (2.1)
Firmware: V180
User Agent: Mozilla/5.0 (Mobile; rv:34.0) Gecko/34.0 Firefox/34.0
Device: Flame 2.0 (shallow flash, 319MB mem)
BuildID: 20141013043753
Gaia: 21fc294d6c9b78997142153fc32c3175b4835a89
Gecko: 93530962cca3
Version: 32.0 (2.0)
Firmware: V180
User Agent: Mozilla/5.0 (Mobile; rv:32.0) Gecko/32.0 Firefox/32.0
-----------
This issue does NOT occur on Flame base image v180 only. Date and time continues to display correctly after rebooting the phone with airplane mode turned on.
QA Whiteboard: [lead-review+] → [QAnalyst-Triage?][lead-review+]
Flags: needinfo?(jmitchell)
Keywords: qawanted
Updated•10 years ago
|
QA Whiteboard: [QAnalyst-Triage?][lead-review+] → [QAnalyst-Triage+][lead-review+]
Flags: needinfo?(jmitchell)
Comment 11•10 years ago
|
||
(In reply to Pi Wei Cheng [:piwei] from comment #10)
> I'm able to reproduce the issue on Flame 2.2 master, Flame 2.1, and Flame
> 2.0.
>
> Observed behavior on Flame 2.1: After rebooting the phone with airplane mode
> turned on, the phone is in a date 3 days earlier and also in different time
> before rebooting. The date&time adjust itself to the correct ones when I
> disable airplane mode (data doesn't need to be turned on, and I didn't have
> wifi connection either).
>
> Observed behavior on Flame 2.0 and Flame 2.2: After rebooting with airplane
> mode turned on, the time is about 6 hours earlier than it should but it's on
> the same date.
>
> Device: Flame 2.2 Master (shallow/full flash, 319MB mem)
> BuildID: 20141013042753
> Gaia: 2a536e4df82410178d8440cc710d8f838a95a0b9
> Gecko: 71edd80236b2
> Version: 35.0a1 (2.2 Master)
> Firmware: V180
> User Agent: Mozilla/5.0 (Mobile; rv:35.0) Gecko/35.0 Firefox/35.0
>
> Device: Flame 2.1 (shallow flash, 319MB mem)
> BuildID: 20141010110704
> Gaia: d18e130216cd3960cd327179364d9f71e42debda
> Gecko: 610ee0e6a776
> Version: 34.0a2 (2.1)
> Firmware: V180
> User Agent: Mozilla/5.0 (Mobile; rv:34.0) Gecko/34.0 Firefox/34.0
>
> Device: Flame 2.0 (shallow flash, 319MB mem)
> BuildID: 20141013043753
> Gaia: 21fc294d6c9b78997142153fc32c3175b4835a89
> Gecko: 93530962cca3
> Version: 32.0 (2.0)
> Firmware: V180
> User Agent: Mozilla/5.0 (Mobile; rv:32.0) Gecko/32.0 Firefox/32.0
>
> -----------
>
> This issue does NOT occur on Flame base image v180 only. Date and time
> continues to display correctly after rebooting the phone with airplane mode
> turned on.
Wesly, this does sound like a vendor bug. Can you help follow-up with T2M here ?
Flags: needinfo?(bbajaj) → needinfo?(wehuang)
Comment 12•10 years ago
|
||
Hi Pi Wei:
Would you help verify this again with v184 base image (FFOS 2.0)? If that works then try with Shallow flash to 2.1 & 2.2. (my hope is it works for them all)
The reason is, in v184 T2M has added a QCT fix to "remember" the time after restarting phone (which is intended to fix bug 1069863, though QA can still met this in some corner cases), thus I think in your case (doesn't set device time to some extreme one) this solution should be helpful.
Thank you.
Flags: needinfo?(wehuang) → needinfo?(pcheng)
Comment 13•10 years ago
|
||
(In reply to Wesly Huang from comment #12)
> Would you help verify this again with v184 base image (FFOS 2.0)? If that
> works then try with Shallow flash to 2.1 & 2.2. (my hope is it works for
> them all)
Test results:
v184 base-only - issue does NOT repro
v184 base + 2.1 - issue DOES repro. Phone boots up to a date yesterday with a wrong time
v184 base + 2.2 - issue DOES repro. Phone boot up to the correct day but wrong time
The results are the same as v180 tests.
2.1 & 2.2 environmental variables:
Device: Flame (shallow flash, 319MB mem)
BuildID: 20141015143144
Gaia: 477a9e61c3edf12f32a62a19d329cd277202cc6b
Gecko: 67573e422a0f
Version: 34.0 (2.1)
Firmware: v184
User Agent: Mozilla/5.0 (Mobile; rv:34.0) Gecko/34.0 Firefox/34.0
Device: Flame (shallow flash, 319MB mem)
BuildID: 20141016070843
Gaia: 5c636a7a54b2c86d8ff6bc1aa1e5f9594c7bc586
Gecko: 77f3ca1fe052
Version: 36.0a1 (2.2 Master)
Firmware: v184
User Agent: Mozilla/5.0 (Mobile; rv:36.0) Gecko/36.0 Firefox/36.0
Flags: needinfo?(pcheng)
Comment 14•10 years ago
|
||
Thanks PiWei, sorry I was not aware the status of v180 base image. Anyway to me it looks like no problem with vendor's SW image, and issue occurs once put new Gaia/Gecko above?
@Bhavana: what's your view about it? Per PiWei's v180/v184 result it's ok with vendor's release, and issue only seen after shallow flash 2.0/2.1/2.2.
Flags: needinfo?(bbajaj)
Comment 16•10 years ago
|
||
I still have the issue in v188 base image (after v2.1 full flash on top of v188).
Comment 18•10 years ago
|
||
Connecting to Internet makes no difference in my case using v188 base image and 2.2 with today's OTA update, the time and date displayed are still wrong after restarting the phone.
Comment 19•10 years ago
|
||
B2G 2.2 20141101040202 on Flame (v188 base image)
There seems to be a dependency on the presence of a SIM card and the slot which it uses for this issue to reproduce:
No SIM card: FAIL, wrong time
1 SIM card in slot 1 ("3G"): PASS, time correct
1 SIM card (same as before) in slot 2 ("2G"): FAIL, wrong time
2 SIM cards: previously used in slot 1, new one in slot 2: FAIL, wrong time
But this should maybe treated as separate bug if that's only because the time gets fixed by time retrieval from the cellular network.
Comment 20•10 years ago
|
||
B2G 2.1 20141102001201 Flame (v180)
My strategy to keep the clock in sync is to always keep "Set Automatically" to false. After every reboot I go there, set it to on, let it sync, and then turn it off again. Any other way will get me a bad date/time (if I let in ON it will sync to some junk date). Maybe the use case of airplane-mode + "Set Automatically" OFF would be a good place to start fixing the issue of not persisting the clock?
Comment 24•10 years ago
|
||
(In reply to Wesly Huang from comment #14)
> Thanks PiWei, sorry I was not aware the status of v180 base image. Anyway to
> me it looks like no problem with vendor's SW image, and issue occurs once
> put new Gaia/Gecko above?
>
> @Bhavana: what's your view about it? Per PiWei's v180/v184 result it's ok
> with vendor's release, and issue only seen after shallow flash 2.0/2.1/2.2.
Looks like the follow-up comments and the DUP's reported could point this to be a vendor issue. can you help follow-up ?
Flags: needinfo?(bbajaj) → needinfo?(wehuang)
Comment 25•10 years ago
|
||
Strange, after comment#14 all I see is issue repro. after shallow flash?
qawanted to check if this can be seen in latest vendor release v188.
Keywords: qawanted
Comment 26•10 years ago
|
||
Just to be clear, I would like to see it this can be repro. w/ "pure" vendor release, v188 base image. Thanks. keep ni on me for tracking.
Comment 27•10 years ago
|
||
Here are my results with the following 188 base image
Environmental Variables:
Device: Flame v188 Base
BuildID: 20141016183911
Gaia: 8c5c956ee6909408e29f375cc7d843a03d92f3d8
Version: 32.0 (2.0)
Firmware: V188
User Agent: Mozilla/5.0 (Mobile; rv:32.0) Gecko/32.0 Firefox/32.0
Prerequisite: Time and location set manually in FTU after Flashing to the Base.
1. Disabled Wifi and Data
2. Enabled Airplane Mode
3. Power off the device
4. Set Test A,B or C.
--------------------------
Test A: Power on with AT&T sim in slot 1: RESULT - Pass (correct time and date)
Test B: Power on with AT&T sim in slot 2: RESULT - Pass (correct time and date)
Test C: Power on with No sim card installed: RESULT - Pass (correct time and date)
***NOTES: I only got the correct results when Airplane mode was ENABLED. If i instead had wifi and/or Data enabled, Test C fails and shows the wrong time and date. However for this test I was trying to stick to the STR's provided by the reporter.
If you would like me to provide further results, please specify the scenario you would like run as there are many combos for time and date checking with various setups.
QA Whiteboard: [QAnalyst-Triage+][lead-review+] → [QAnalyst-Triage?][lead-review+]
Flags: needinfo?(jmitchell)
Keywords: qawanted
QA Contact: croesch
Updated•10 years ago
|
QA Whiteboard: [QAnalyst-Triage?][lead-review+] → [QAnalyst-Triage+][lead-review+]
Flags: needinfo?(jmitchell)
QA Contact: croesch
Comment 28•10 years ago
|
||
There are a number of duplicates on bug 1021698 and bug 1069863 (which are both dupes of this bug, kinda) about *only* the Last Updated field in Settings.
That field is *not* updated from 1970 after connecting to the internets. Same bug as this one? Or different?
Comment 29•10 years ago
|
||
(In reply to Dietrich Ayala (:dietrich) from comment #28)
> That field is *not* updated from 1970 after connecting to the internets.
> Same bug as this one? Or different?
It's arguably the same bug because what's causing that field to be set to early 1970 is the following sequence:
- The phone starts up, the clock has been reset to the Epoch (1970-01-01T00:00:00Z)
- The update service confirms the application of an update thus needs to populate the "Last Updated" field; to do so it reads the clock
- The clock hasn't been set to the proper date yet, so the update service gets the 1970-ish date
- The update service stores this date in a pref so even when the clock is finally adjusted to the correct date, the wrong one will stick
If the clock value would be properly persisted between reboots we wouldn't have this issue hence I think it's safe to consider it a duplicate.
Comment 30•10 years ago
|
||
Thanks Cody, then clear ni from me since test pass in base image and pls feel free to ni me again if we need support/fix from vendor.
Flags: needinfo?(wehuang)
Comment 31•10 years ago
|
||
FYI I've been testing the v18D base image plus the current gecko+gaia nightly build and I can still reproduce this problem.
Comment 32•10 years ago
|
||
FWIW, this prevents users from logging in to any 2-factor-auth protected sites like Gmail, Facebook, Github, etc., because the authenticator protocol relies on having the correct time. If your phone has a bogus time, auth apps like https://marketplace.firefox.com/app/gauth-authenticator just generate incorrect codes, and users can't get past the login page.
(gsvelto mentioned this over on dupe bug 1069863 comment 12, but I thought it was important to bring up on this main bug as well. I hit this issue myself while visiting family who live in a rural no-cell-service area over the holidays.)
Comment 33•10 years ago
|
||
FWIW, the observation I just made:
after a nightly update my Flame was a few minutes ahead of time *although* WiFi connection was active and SIM2 registered to 2G network (no data there).
toggeling automatic time setting off and on again made it even *worse* - then it was almost 30min ahead of time.
After an additional reboot, everything was correct again (WiFi still active)
Comment 35•10 years ago
|
||
Hi Ralph:
Could you please try to uncheck "Set automatically" from "Date & Time", and try your repo. STR again?
Note:
"Set automatically" needs to be shown when device have NITZ or SNTP information.
Flags: needinfo?(rdaub)
Reporter | ||
Comment 37•10 years ago
|
||
Hi Shawn Ku,
I tested it on Base Image v18D, and noticed that the "Set Automatically" is no longer displayed when the device is not connected to the Internet (no NITZ or SNTP information I'm assuming) - is there a bug number for this change? This behavior of a menu item "simply disappearing" without any explanation does not seem user friendly.
RESULTS:
v18D Base Image
- Restarting the device KEEPS the time
- Unchecking "Set automatically" and restarting the device KEEPS the time
- Turning off WiFi and restarting the device KEEPS the time
V18D Base Image with latest v2.2.0.0-prerelease (BuildID 20150122002808)
- Restarting the device KEEPS the time
- Unchecking "Set automatically" and restarting the device KEEPS the time
- Leaving "Set automatically" unchecked, WiFi off, changing the time significantly, and restarting the device DOES NOT KEEP the time. The time reverts back to what it was prior to changing the time manually.
Additionally, there seems to me a small difference between the device's time and what is shown on Settings. On a few occasions, the "manually configured time" inside the Settings application was 1-minute ahead of the time shown in the notification bar. (see the screenshot in comment 37 below)
Flags: needinfo?(rdaub)
Reporter | ||
Comment 38•10 years ago
|
||
Comment 39•10 years ago
|
||
(In reply to Ralph Daub [:rdaub] from comment #38)
> Created attachment 8553440 [details]
> Time difference between Settings and Notification bar
Something like this is discribed here: https://bugzilla.mozilla.org/show_bug.cgi?id=1116091#c16 and following comments
Reporter | ||
Comment 40•10 years ago
|
||
Shawn,
Do you know if there is a bug open for the behavior change in the "set time automatically", where that menu option disappears when there is no NITZ or SNTP information? Is this done on purpose, or was there any discussion behind this?
Comment 41•10 years ago
|
||
(In reply to Ralph Daub [:rdaub] from comment #40)
> Shawn,
>
> Do you know if there is a bug open for the behavior change in the "set time
> automatically", where that menu option disappears when there is no NITZ or
> SNTP information? Is this done on purpose, or was there any discussion
> behind this?
Ralph:
The logic for show/hide "set time automatically" wasn't changed for a long period of time.
Setting AP observes the key - "time.clock.automatic-update.available" written by radioInterfaceLayer.js.
And Gecko will update the setting db by receiving NITZ or SNTP information.
Below seems a new issue which does not included in my radar.
--------------------------------------------------------------
I will check it later.V18D Base Image with latest v2.2.0.0-prerelease (BuildID 20150122002808)
- Restarting the device KEEPS the time
- Unchecking "Set automatically" and restarting the device KEEPS the time
- Leaving "Set automatically" unchecked, WiFi off, changing the time significantly, and restarting the device DOES NOT KEEP the time. The time reverts back to what it was prior to changing the time manually.
--------------------------------------------------------------
Please file a bug for below case, and ni?gmarty@mozilla.com to check.
--------------------------------------------------------------
Additionally, there seems to me a small difference between the device's time and what is shown on Settings. On a few occasions, the "manually configured time" inside the Settings application was 1-minute ahead of the time shown in the notification bar. (see the screenshot in comment 37 below)
Comment 43•10 years ago
|
||
Per comment 37, it looks like original issue symptom is not there.
Please file a new bug for tracking the new issue be found.
Flags: needinfo?(sku)
Comment 44•10 years ago
|
||
Still reproducing on a newly flashed v188 base image (latest publicly available image) + latest production 2.2 build for the Flame. Connecting to the Internet doesn't seem to make any difference.
I don't understand why we've shipped releases for our reference device which can't keep the time, but in my opinion we definitely shouldn't ship another one. This is a real dogfooding blocker.
What's the latest thinking on the cause of this bug?
blocking-b2g: --- → 2.2?
Comment 45•10 years ago
|
||
Hey Ben, our latest available image is v18D (albeit not public yet -- I hope it will be soon), so it would make sense that you test with this image instead.
Comment 46•10 years ago
|
||
Hi Julien, it would be great to hear whether v18D will fix this but I intentionally dogfood the latest publicly available build, otherwise it isn't dogfood.
Comment 47•10 years ago
|
||
v18D still exhibits the same behavior.
Comment 48•10 years ago
|
||
(In reply to Gabriele Svelto [:gsvelto] from comment #47)
> v18D still exhibits the same behavior.
Since v18D became public I just updated my dogfood device, and I can confirm this is the case :(
Gabriele, do you have any idea what the cause is?
Flags: needinfo?(gsvelto)
Comment 49•10 years ago
|
||
(In reply to Ben Francis [:benfrancis] from comment #48)
> Gabriele, do you have any idea what the cause is?
I've spent a lot of time trying to figure it out in bug 1051083 but couldn't come up with a definitive answer. What came up in various discussions is that the Flame doesn't have a traditional battery-backed RTC clock and thus is unable to keep the time across reboots using normal means. To do so it uses the time taken from the modem instead via a vendor-specific blob which interfaces directly with Gecko via XPCOM. The said component isn't compatible with our current master (because of differences in the XPCOM interfaces it expects) and thus doesn't work correctly. :gerard-majax tried hacking our interfaces to make it run nevertheless but with little success.
Flags: needinfo?(gsvelto)
Comment 50•10 years ago
|
||
(In reply to Gabriele Svelto [:gsvelto] from comment #49)
> The said component isn't
> compatible with our current master (because of differences in the XPCOM
> interfaces it expects) and thus doesn't work correctly. :gerard-majax tried
> hacking our interfaces to make it run nevertheless but with little success.
Bug 1110010 comment 21 contains a sketch of what Gecko proper is missing here.
Comment 51•10 years ago
|
||
(In reply to Michael Vines [:m1] [:evilmachines] from comment #50)
> Bug 1110010 comment 21 contains a sketch of what Gecko proper is missing
> here.
Thanks, I wasn't CC'd on that bug otherwise I'd have acted upon it.
Comment 52•10 years ago
|
||
(In reply to Gabriele Svelto [:gsvelto] from comment #49)
> the Flame doesn't have a traditional battery-backed RTC clock and thus
> is unable to keep the time across reboots using normal means.
Aha! I have suspected this might be the case for a long time (I remember another device which had the same issue), but I had no idea how to test for it.
(In reply to Michael Vines [:m1] [:evilmachines] from comment #50)
> Bug 1110010 comment 21 contains a sketch of what Gecko proper is missing
> here.
Thanks Michael! Hopefully this is the key to a fix.
Reporter | ||
Comment 53•10 years ago
|
||
I've been able to replicate this issue once again in the last two weeks. Running Flame Full Image v2.1 on top of Base Image v18D:
Gaia-Rev e8eba437af02820f74d122aec83b6001df6f89e3
Gecko-Rev https://hg.mozilla.org/releases/mozilla-b2g34_v2_1/rev/9d04f9149ca4
Build-ID 20150217001459
Version 34.0
Device-Name flame
FW-Release 4.4.2
FW-Incremental eng.cltbld.20150213.035917
FW-Date Fri Feb 13 03:59:27 EST 2015
Bootloader L1TC000118D0
Reporter | ||
Updated•10 years ago
|
Summary: [Flame v2.0] [Clock Time] - After restarting the phone, the time and date displayed are wrong until there is a connection to the Internet → [Flame v2.1] [Clock Time] - After restarting the phone, the time and date displayed are wrong until there is a connection to the Internet
Comment 54•10 years ago
|
||
We were able to repro this easily on a Flame in B2G triage (like others have, above). Blocking on the relation between correct time display and account authentication noted in comment #32, as it prevents users from accomplishing tasks.
blocking-b2g: 2.2? → 2.2+
Comment 55•10 years ago
|
||
I can confirm that time is correct after phone restart when 188 base image with master build (currently 3.0.0.0-prerelease) shallow flashed over is used. I used nightly from February 17th.
Comment 56•10 years ago
|
||
Marek, if your wifi or gsm is enabled, then the time is synchronized by other means. Can you confirm you tried this with Internet disabled?
Comment 57•10 years ago
|
||
(In reply to Julien Wajsberg [:julienw] from comment #56)
> Marek, if your wifi or gsm is enabled, then the time is synchronized by
> other means. Can you confirm you tried this with Internet disabled?
Steps I took to reproduce:
1. turned off automatical time synchronization
2. set time by hand
3. turned airplane mode on
4. turned cell phone off for more than one hour
5. turned cell phone back on
After I turned the cell phone on, time was correct. I cannot confirm skew as I did not measure it.
Comment 58•10 years ago
|
||
Hello.
I am terribly sorry to announce that I am unable to reproduce the correct phone behavior I described here yesterday :-( For some kind of reason my phone stopped to be able to keep time over restarts. I do not know what caused it. Truth is I was setting time with "adb shell toolbox date" command instead of just setting it automatically or by hand from gaia. After that I tried to reset the phone, flash it again without restoring backed up data, but I was unable to reproduce correct behavior. :-(
Have no idea what happened.
Sorry.
-Marek
Comment 59•10 years ago
|
||
Hello.
First, let me applogize for spamming. Second, I was able to reproduce correct behavior today.
1. Flash phone with v188.
2. Get B2G source tree, repo sync, git pull for Gaia.
3. Run build.sh, flash.sh.
4. Turn off automatical time synchronization, set time by hand (probably adb shell toolbox date command would work too), set Airplane Mode on, turn phone off, take SIM card out.
After those steps when I turned phone off and on again, time was correct.
I even tried to shallow flash the phone with production nightly build I downloaded on February 17th. Time is still correct after powering the phone off and on.
Please tell me anyone else is able to reproduce this.
Regards.
-Marek
Comment 61•10 years ago
|
||
So, it works correctly now as Comment 59 menetioned, qawanted to check.
Flags: needinfo?(htsai)
Keywords: qawanted
Comment 62•10 years ago
|
||
Changing title to better reflect the bug - it doesn't only affect 2.1; it's affecting all branches.
This issue still reproduces on latest master nightly engineering build.
What I did:
0) Phone has AT&T SIM card on slot 1
1) Base phone to v188 image
2) Shallow flash latest nightly master gaia + gecko on top
3) Progress past FTE without changing anything
4) Go to Settings > Date & Time > toggle off Set Automatically, change timezone to Pacific Time (default is Eastern Standard Time) > toggle ON Set Automatically again (observe time is now correct)
5) Turn on Airplane mode and reboot
- Observe time is wrong after reboot, though it is still on the same date.
I got the same result for full flashing with same STR.
It has been established that this occurs on v18D base image on previous comments as well.
Device: Flame 3.0 Master (shallow flash/full flash/319MB memory)
BuildID: 20150306010207
Gaia: 7a91c16bfa348be8b25e09719178efa051512988
Gecko: 0189941a3fd5
Gonk: e7c90613521145db090dd24147afd5ceb5703190
Version: 39.0a1 (3.0 Master)
Firmware Version: v188
User Agent: Mozilla/5.0 (Mobile; rv:39.0) Gecko/39.0 Firefox/39.0
QA Whiteboard: [QAnalyst-Triage+][lead-review+] → [QAnalyst-Triage?][lead-review+]
Flags: needinfo?(ktucker)
Keywords: qawanted
Summary: [Flame v2.1] [Clock Time] - After restarting the phone, the time and date displayed are wrong until there is a connection to the Internet → [Flame][Clock Time] After restarting the phone, the time and date displayed are wrong until there is a connection to the Internet
Updated•10 years ago
|
QA Whiteboard: [QAnalyst-Triage?][lead-review+] → [QAnalyst-Triage+][lead-review+]
Flags: needinfo?(ktucker)
Comment 63•10 years ago
|
||
Looks discussion and solution are on-going in bug 1110010.
See Also: → 1110010
Comment 64•10 years ago
|
||
Hi Hsin-Yi, so this one can be dup to bug 1110010 ?
Flags: needinfo?(htsai)
Comment 65•10 years ago
|
||
(In reply to howie [:howie] from comment #64)
> Hi Hsin-Yi, so this one can be dup to bug 1110010 ?
Yes, per my understanding, bug 1110010 also aims at "keeping time and date right after rebooting (remembering the time from before)."
This sounds a duplicate to me.
Flags: needinfo?(htsai)
Updated•10 years ago
|
Status: NEW → RESOLVED
Closed: 10 years ago
Resolution: --- → DUPLICATE
You need to log in
before you can comment on or make changes to this bug.
Description
•