1048154 - [Flame] Can't set the date/time in manual mode

Status: RESOLVED WONTFIX

(Firefox OS Graveyard :: Vendcom, defect)

Description

[Mark Banner (:standard8)]

This started on one of my devices a couple of days ago. I've just checked my other device, and that also fails.

STR
---
1) Have your device in manual mode for ages (due to bug 1032101).
2) Device suddenly decides to use incorrect time from a month ago.
3) Try and set the date and/or time.

=> Date & Time are set on the display

4) Reboot the device

=> Date & Time return to what they were.

I also did this on a second device which was showing a correct time, and tried to change it to an incorrect time, and the same effects were seen.

First device: v122 base image with 20140803160202, gaia rev 5fd14b8b
Second device: v122 base image with 20140802040202, gaia rev 5fd14b8b

Comment 1

[Jason Smith [:jsmith]]

QA Wanted for branch checks.

Comment 2

[Cody Roesch [:croesch]]

This bug repro's on: Flame 2.1, Flame 2.0, Flame 1.4

Actual Results: Setting the Time and Date to Automatically [off], shows incorrect time. Setting the correct time then rebooting will result in previous wrong time being set again.

Repro Rate: 5/5

Environmental Variables:
Device: Flame Master
Build ID: 20140807084328
Gaia: 54c3c19d439f7dbafda5c6cc3b4850b545a068ba
Gecko: 2f198e81ed98
Version: 34.0a1 (Master)
Firmware Version: v123
------------------------------------------------
Environmental Variables:
Device: Flame 2.0
BuildID: 20140807215456
Gaia: 8d4599d18fbfc41f88ea494ab9cce0bb99cffac3
Gecko: aad73d079368
Version: 32.0 (2.0) 
Firmware Version: v123
------------------------------------------------
Environmental Variables:
Device: Flame 1.4
Build ID: 20140808033135
Gaia: 2b2849a61cd38e909ed1c3e4586d104bc96f7001
Gecko: 931bf8651711
Version: 30.0 (1.4)
Firmware Version: v123
------------------------------------------------
------------------------------------------------

This bug does NOT repro on: Buri 2.1

Actual Result: Setting the Time and Date to Automatically [off], shows correct time. Setting the correct time then rebooting will keep the correct time.

Repro Rate: 0/5 attempts

Environmental Variables:
Device: Buri Master
BuildID: 20140806134618
Gaia: 5e6ef81cb9e917657ce050f598229dfc83c58b8f
Gecko: a31cd48facbf
Version: 34.0a1 (Master) 
Firmware Version: v1.2device.cfg

Comment 3

[Joshua Mitchell (Inactive)]

not a regression - based on those branch checks

Comment 4

[Joshua Mitchell (Inactive)]

[Blocking Requested - why for this release]: nomming for 2.0 because this is a pretty bad bug - we should never lose data that the user is intentionally setting themselves. High level of user frustration.

Comment 5

[Mark Banner (:standard8)]

(In reply to Joshua Mitchell [:Joshua_M] from comment #3)
> not a regression - based on those branch checks

Err, this *used* to work, certainly as of a month or two ago.

Otherwise I'd have never been able to set the time correctly (bug 1032101 has always caused automatic mode to have the wrong time for me).

Comment 6

[Jason Smith [:jsmith]]

QA Wanted to double check the branch checks per comment 5.

Comment 7

[Jayme Mercado [:JMercado] (Inactive 3/4/2016)]

This issue DOES occur on the latest 2.1 Flame, 2.0 Flame, and 1.4 Flame.

Manually setting the time only lasts until the phone is restarted.

Environmental Variables:
Device: Flame Master
BuildID: 20140808131609
Gaia: 2d2475b521351e200136e463358e6c8e91957702
Gecko: 08bfcc7c6789
Version: 34.0a1 (Master) 
Firmware Version: v123
User Agent: Mozilla/5.0 (Mobile; rv:34.0) Gecko/34.0 Firefox/34.0

Environmental Variables:
Device: Flame 2.0
BuildID: 20140808095913
Gaia: 4c8c6569f2fded3c610cb6baf2e86355b1004653
Gecko: 45fb39baedc6
Version: 32.0 (2.0) 
Firmware Version: v123
User Agent: Mozilla/5.0 (Mobile; rv:32.0) Gecko/32.0 Firefox/32.0

Environmental Variables:
Device: Flame 1.4
BuildID: 20140808033135
Gaia: 2b2849a61cd38e909ed1c3e4586d104bc96f7001
Gecko: 931bf8651711
Version: 30.0 (1.4) 
Firmware Version: v123
User Agent: Mozilla/5.0 (Mobile; rv:30.0) Gecko/30.0 Firefox/30.0


This issue does NOT occur on the latest Buri 2.1.

The time setting persists.

Environmental Variables:
Device: Buri Master
BuildID: 20140806134618
Gaia: 5e6ef81cb9e917657ce050f598229dfc83c58b8f
Gecko: a31cd48facbf
Version: 34.0a1 (Master) 
Firmware Version: v1.2device.cfg
User Agent: Mozilla/5.0 (Mobile; rv:34.0) Gecko/34.0 Firefox/34.0

Comment 8

[Joshua Mitchell (Inactive)]

after some spot-checking I can conclude that everyone is correct
 - The branch checks were correct
 - Mark is correct - this is a regression and 'used to work'

I found the following: 
20140620094247 - can set correctly but not correct after restart
*20140627063530 - can set correctly - persists after restart
20140708061447 - can set correctly but not correct after restart

*so we can see that at one point this was broken and then fixed (or at least 'working') and then broke again

Comment 9

[Pi Wei Cheng [:piwei] (inactive)]

Unable to find a regression window due to the bug occurs to earliest Flame central build (20140417000006) that we have available.

The phone ALWAYS reboots to a date/time in January 1970 with a central Flame build. But with only base image v122 or v123, the bug does NOT repro. So the regression occurred in between a date that we can't find.

Comment 8 mentioned build ID 20140627063530 did not reproduce the bug which is NOT true. I've tried multiple times and it does reproduce the bug.

To avoid confusion, I'm writing down what I did:

0) A SIM card is present in the Flame
1) Flash a Flame central Gaia+Gecko build on top of v122 or v123 gonk.
2) Progress through FTU/FTE without changing any settings on it.
3) Unplug the phone from USB (so it does not influence the reboot later)
4) Go to Setting > Date & Time > un-toggle Set Date & Time Automatically, and manually set time to current time.
5) Long press power button and select Restart.

- observe the time goes to sometime in January 1970 after reboot.

Comment 10

[Joshua Mitchell (Inactive)]

Unfortunately I do not seem to be able to repro my one instance of a "working" build. I've used the same device and set-up as before and not gotten a repro (of it working - 0/15 tries). Either I was incorrect in my findings initially or the 'working' is incredibly intermittent. 

I'm leaving the regression tag alone but without a solid 'working build' (which we have looked around for but have not been able to find) we will not be able to do a regression-window.

Comment 12

[Manuel Casas Barrado [:mancas]]

I've been researching this bug and it's funny because when you try to change the date manually twice, it works. Only fails the first time you try to change it.

So I'm going to make a deep research. If anyone has any ideas...you're welcome

Comment 13

[Manuel Casas Barrado [:mancas]]

Hi Arthur, I'm trying to solve this bug but I don't understand how the automatically date feature
works.

It seems when you toggle "Set automatically" on Settings/Date&Time panel, a "moztimechange" event is thrown twice and I don't really know where the system is setting the new date time.

Could you explain me how it works? Thanks!

Comment 14

[Mark Banner (:standard8)]

(In reply to Manuel Casas Barrado [:mancas] from comment #12)
> I've been researching this bug and it's funny because when you try to change
> the date manually twice, it works. Only fails the first time you try to
> change it.

This doesn't work for me currently for either of my phones - although I've had them in manual mode for a couple of months now, so maybe that's different (it actually sounds a bit like what was seen in bug 1032233).

I'm willing to try re-flashing one or both of them, if you want me to do specific tests, feel free to drop me a line over irc or email.

Comment 15

[Kai-Chih Hu [:khu]]

Manuel Casas Barrado, since you're looking at this bug, would you mind taking the ownership on this bug? Thanks.

Comment 16

[Manuel Casas Barrado [:mancas]]

(In reply to Kevin Hu [:khu] from comment #15)
> Manuel Casas Barrado, since you're looking at this bug, would you mind
> taking the ownership on this bug? Thanks.

Sorry, it seems I forgot to save changes

Comment 17

[Arthur Chen [:arthurcc][inactive after 6/30]]

Hi Manuel, as the issue is related to the gecko so I'm not able to provide more useful information. From gaia we simply set the key "time.clock.automatic-update.enabled" and then gecko determine the time by itself.

Comment 18

[Manuel Casas Barrado [:mancas]]

(In reply to Arthur Chen [:arthurcc] from comment #17)
> Hi Manuel, as the issue is related to the gecko so I'm not able to provide
> more useful information. From gaia we simply set the key
> "time.clock.automatic-update.enabled" and then gecko determine the time by
> itself.

Ok, thanks Arthur. I think there is a bug in a Gecko deamon because when you toggle "Set automatically switch" only an API call is done. But if you disabled this option and set a date/time manually, the new date is updated, however, if you enabled again the "set automatically button", two API calls are done. This cause an overlapping in the calls and the result is a wrong date. If you want to reproduce this, follow this steps:
1. Go to settings/Date&time panel
2. Disable "Set automatically"
3. Set manually a new date or time
4. Enable "Set automatically"
5. See a wrong date

Following the trace, a moztimechange event is throw two times, once you set up manually a date.

Comment 19

[bhavana bajaj [:bajaj]]

Discussed this with :fabrice and he can look at this issue, but the comments here seem confusing on if this is reproducible consistently. Can we please try with the latest base image available to confirm this regression ?

Comment 20

[Robert Kaiser]

I wonder if bug 1032233 comment #13 and following are related to this.

Comment 21

[Pi Wei Cheng [:piwei] (inactive)]

(In reply to bhavana bajaj [:bajaj] from comment #19)
> Can we please try with the latest base image available to confirm this regression ?

Comment 9 is still true in latest build with v123 base. Bug repro rate: 2/2

Tested on:
Device: Flame
BuildID: 20140819054116
Gaia: b33b4d9558e0b9eabbfda7be23435e2b38fd40bf
Gecko: a38daccaa557
Version: 34.0a1 (2.1 Master)
Firmware: V123
User Agent: Mozilla/5.0 (Mobile; rv:33.0) Gecko/33.0 Firefox/33.0

Comment 22

[Gregor Wagner [:gwagner]]

Maybe Aus can help out here?

Comment 23

[Aus Lacroix [:aus]]

I'll take a look at this ASAP!

Comment 25

[Mark Banner (:standard8)]

Potentially useful extra information I sent to Manuel just over a week ago:

- I flashed v123 of the base image (using the gecko+gaia it installs), and set it up without wifi and without a data connection (to avoid issue of automatically set date & time getting in the way).

=> Changing the date, powering off & starting up again KEPT the date change

- Then I did a shallow flash of Gaia and Gecko for latest master, again no wifi, no data connection

=> Changing the date, powering off & starting up again LOST the date change - returning to the original date and time.

Comment 26

[Aus Lacroix [:aus]]

(In reply to Mark Banner (:standard8) from comment #25)
> Potentially useful extra information I sent to Manuel just over a week ago:
> 
> - I flashed v123 of the base image (using the gecko+gaia it installs), and
> set it up without wifi and without a data connection (to avoid issue of
> automatically set date & time getting in the way).
> 
> => Changing the date, powering off & starting up again KEPT the date change
> 
> - Then I did a shallow flash of Gaia and Gecko for latest master, again no
> wifi, no data connection
> 
> => Changing the date, powering off & starting up again LOST the date change
> - returning to the original date and time.

That's is hugely useful! Thanks Mark!

Comment 27

[Aus Lacroix [:aus]]

This is most likely a bug with the v122 or v123 base image.

One doesn't even need b2g to reproduce this.

STRs:

1. Boot up phone, connect via adb shell, stop b2g process (you can hack the scripts to skip starting b2g automatically).
2. Set date ('date -s 20140825', for example).
3. Reboot (from shell, 'reboot').
4. As soon as device starts booting up and you can connect via adb shell, look at the date using 'date'.

You'll notice it reset itself to what is essentially a timestamp of '0'.

Comment 28

[Jason Smith [:jsmith]]

QA Wanted to see if this reproduces with the kitkat image.

Comment 29

[Aus Lacroix [:aus]]

(In reply to Ghislain Aus Lacroix [:aus] from comment #27)
> This is most likely a bug with the v122 or v123 base image.
> 
> One doesn't even need b2g to reproduce this.
> 
> STRs:
> 
> 1. Boot up phone, connect via adb shell, stop b2g process (you can hack the
> scripts to skip starting b2g automatically).
> 2. Set date ('date -s 20140825', for example).
> 3. Reboot (from shell, 'reboot').
> 4. As soon as device starts booting up and you can connect via adb shell,
> look at the date using 'date'.
> 
> You'll notice it reset itself to what is essentially a timestamp of '0'.

Oh great Obi Wu Kenobi, does this sound more like a hardware or driver bug to you?

Comment 30

[Aus Lacroix [:aus]]

> This is most likely a bug with the v122 or v123 base image.

Confirmed that v122 *and* v123 exhibit the same issue. 'date -s' always fails to set the time so that it is preserved after reboot.

Comment 31

[Jayme Mercado [:JMercado] (Inactive 3/4/2016)]

I was unable to reproduce this issue on the v165 KitKat Base image.

Comment 33

[Peter Bylenga [:PBylenga]]

Smoketest blocker on v123 base from duplicate bug 1057589.

Comment 34

[Jason Smith [:jsmith]]

(In reply to Ghislain Aus Lacroix [:aus] from comment #30)
> > This is most likely a bug with the v122 or v123 base image.
> 
> Confirmed that v122 *and* v123 exhibit the same issue. 'date -s' always
> fails to set the time so that it is preserved after reboot.

Moving to vendcom per proof of this being a vendor bug & adding needinfo on Francis to get someone from T2M to take a look.

Comment 35

[Michael Wu [:mwu]]

(In reply to Ghislain Aus Lacroix [:aus] from comment #27)
> This is most likely a bug with the v122 or v123 base image.
> 
> One doesn't even need b2g to reproduce this.
> 
> STRs:
> 
> 1. Boot up phone, connect via adb shell, stop b2g process (you can hack the
> scripts to skip starting b2g automatically).
> 2. Set date ('date -s 20140825', for example).
> 3. Reboot (from shell, 'reboot').
> 4. As soon as device starts booting up and you can connect via adb shell,
> look at the date using 'date'.
> 
> You'll notice it reset itself to what is essentially a timestamp of '0'.

This isn't supported, unfortunately. QC hardware has its own special way to set time, which gecko has support for if you have the right extension in gecko. The date command, on the other hand, doesn't use this special API, so dates set via the command won't work. Set the date via the settings app and it should work.

Comment 36

[[:fabrice] Fabrice Desré]

Ok. I know what's happening, but I need to reach out to QC. Stay tuned.

Comment 37

[Aus Lacroix [:aus]]

(In reply to Michael Wu [:mwu] from comment #35)
> (In reply to Ghislain Aus Lacroix [:aus] from comment #27)
> > This is most likely a bug with the v122 or v123 base image.
> > 
> > One doesn't even need b2g to reproduce this.
> > 
> > STRs:
> > 
> > 1. Boot up phone, connect via adb shell, stop b2g process (you can hack the
> > scripts to skip starting b2g automatically).
> > 2. Set date ('date -s 20140825', for example).
> > 3. Reboot (from shell, 'reboot').
> > 4. As soon as device starts booting up and you can connect via adb shell,
> > look at the date using 'date'.
> > 
> > You'll notice it reset itself to what is essentially a timestamp of '0'.
> 
> This isn't supported, unfortunately. QC hardware has its own special way to
> set time, which gecko has support for if you have the right extension in
> gecko. The date command, on the other hand, doesn't use this special API, so
> dates set via the command won't work. Set the date via the settings app and
> it should work.

Ah, that's good to know! However, I think it's the same root issue that's occurring. The call itself to set the time fails so when the device restarts the time is lost.

Comment 38

[Jason Smith [:jsmith]]

Unblocking this for being a vendor bug.

Comment 39

[Mark Banner (:standard8)]

The workaround in bug 1057589 comment 17 works for me. However, I suggest that we keep this bug open until this is publicily available on

https://developer.mozilla.org/en-US/Firefox_OS/Developer_phone_guide/Flame#Updating_your_Flame%27s_software

in either workaround form, or in a fresh release.

Comment 40

[Gabriela [:gaby2300]]

I have this issue in 2.0 and 2.1 with base image 123. It happens every time I reboot or power off my Flame.

Comment 41

[BMO Automation]

Firefox OS is not being worked on