1116672 - [Flame] with activated SIM card, time occasionally resets to the actual time from artificially set time

Status: RESOLVED WORKSFORME

(Remote Protocol :: Marionette, defect)

Description

[No-Jun Park [:njpark]]

Attachment: python marionette test script

With the new nightly build, the lockscreen clock does not display the time set by the following python marionette code:
 _seconds_since_epoch = 1357043430
self.data_layer.set_time(self._seconds_since_epoch * 1000)
self.data_layer.set_setting('time.timezone', 'Atlantic/Reykjavik')

STR:
run attached python marionette script.  
Notice that in the homescreen, the time is displayed correctly, but on the lockscreen, it shows the actual time.

Version Info:
Gaia-Rev        26d479f0fccb7174e06255121e4e938c1b280d67
Gecko-Rev       https://hg.mozilla.org/mozilla-central/rev/88037f94b7d7
Build-ID        20141230160202
Version         37.0a1
Device-Name     flame
FW-Release      4.4.2
FW-Incremental  eng.cltbld.20141230.194008
FW-Date         Tue Dec 30 19:40:19 EST 2014
Bootloader      L1TC000118D0

Note: this does not appear on the previous nightly build.

Comment 1

[Martijn Wargers (dead)]

I had to add "from gaiatest import GaiaTestCase" to the python marionette script. Also had to add "test_" in front of the file to be able to run the test.

What should the time be according to you? And what is the time on the lockscreen for you?
Do you have "time.timezone"/"time.timezone.user-selected" or other time related settings in your testvars.json file?

I get to see 12:31am on the lockscreen and then 1:31pm on the homescreen. Is that what you see?
Also, the time on the lockscreen doesn't seem to continue.

Comment 2

[Martijn Wargers (dead)]

Perhaps there is also some "Automatically set time" setting that needs to be turned off?

Comment 3

[No-Jun Park [:njpark]]

I think this bug is related to Bug 1061797.  

Previously, the scripts never turned off that setting when setting the artificial time. But I'll look into that.

Comment 4

[Dave Hunt [:davehunt] [he/him] ⌚BST]

No-Jun: Try setting the following in setUp or add them to your testvars file:

  time.clock.automatic-update.enabled: false
  time.timezone.automatic-update.enabled: false

Comment 5

[Martijn Wargers (dead)]

Actually, you might have seen a recent regression here, bug 1117981.

Comment 6

[No-Jun Park [:njpark]]

With the latest build, after I add those two lines in my json file, it looks like this:

...
  "settings": {
    "ril.cellbroadcast.disabled": true,
    "time.timezone": "America/Los_Angeles",
    "time.timezone.user-selected": "America/Los_Angeles",
    "time.clock.automatic-update.enabled": "false",
    "time.timezone.automatic-update.enabled": "false"
  },
...

the test works well if I have no mobile/wifi connection.  but if I enable wifi, then set the time manually in the script, the time or timezone does not get set properly. It either does not set the time at all, or it sets the wrong time, probably mixing up the timezone i suspect.  
If I set the time then connect to wifi, it changes the time automatically, so either about setting parameters do not work or I'm using them incorrectly.

and even with above setting parameters, the settings -> date/time shows that 'set time automatically' is still enabled.

Comment 7

[Dave Hunt [:davehunt] [he/him] ⌚BST]

(In reply to No-Jun Park [:njpark] from comment #6)
>     "time.clock.automatic-update.enabled": "false",
>     "time.timezone.automatic-update.enabled": "false"

The values should not be strings.

Comment 8

[No-Jun Park [:njpark]]

(In reply to Dave Hunt (:davehunt) from comment #7)
> (In reply to No-Jun Park [:njpark] from comment #6)
> >     "time.clock.automatic-update.enabled": "false",
> >     "time.timezone.automatic-update.enabled": "false"
> 
> The values should not be strings.

Thanks, tried with the corrected settings.  It does work, until I initiate the lockscreen by  self.device.turn_screen_off() call. Then after I turn on the screen with self.device.turn_screen_on(), the time displayed is changed.  

It is similar to bug 1117981, but since that is verified when reproduced manually, I wonder whether this bug is caused by one of the marionette calls.

Comment 9

[No-Jun Park [:njpark]]

I might have screwed up the order. I'll retry and put an update