1109850 - [Calendar] Events that roll over into the next day are lost when a timezone with a 12+ hour difference is applied.

Status: RESOLVED FIXED

(Firefox OS Graveyard :: Gaia::Calendar, defect)

Description

[jbolton]

Attachment: CalendarTimezoneEventsLostlog.txt

Description:
When a user schedules an event that elapses into the next day and then changes their timezone  to one that contains a 12+ hour difference, the event scheduled is lost.

   
Repro Steps:
1) Update a Flame device to BuildID: 20141210040201
2) Ensure that a US timezone is currently applied.
3) Create an event on the offline calendar that elapses into the next day. (ex. 11pm-12am)
4) Change the timezone settings so that a 12+ hour difference is applied. (ex. Asia: Hong Kong)
5) Return to the offline calendar and observe the previously created event. (Be sure to tap off of the day the event is scheduled and back on in order to refresh the event).
6) Observe.

  
Actual:
The dot indicating that an event was scheduled for that day remains, but the event itself is gone.
  
Expected: 
The event remains and the time is appropriately adjusted to the newly set timezone.

  
Environmental Variables:
Device: Flame 2.2 Master (319mb)(kitkat)(full flash)
BuildID: 20141210040201
Gaia: e17c5656dbf517d48fb61ac9bc92119e023fd717
Gecko: be1f49e80d2d
Gonk: 48835395daa6a49b281db62c50805bd6ca24077e
Version: 37.0a1 (2.2 Master)
Firmware: V188-1
User Agent: Mozilla/5.0 (Mobile; rv:37.0) Gecko/37.0 Firefox/37.
  
Repro frequency: 100%
See attached: Video, logcat

Notes: This bug seems similar too https://bugzilla.mozilla.org/show_bug.cgi?id=796465. Additionally, rebooting the phone will bring the lost event back, but the time elapsed will be inaccurate.


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

Comment 1

[jbolton]

Link to failed test case: https://moztrap.mozilla.org/manage/case/3863/

Comment 2

[Derek Harris [:DerekH] - Dont need info. Last day 6/5/15]

QAwanted for branch checks

Comment 3

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

This issue does NOT occur on Flame 2.1 and Flame 2.2.

Observed behavior: Following STR, at step 6 I see the dot & event content has been updated to 12/25 3:00pm to 4:00pm (originally set to 12/24 11:00pm to 12:00am Pacific time)

Device: Flame 2.1 (shallow flash 319MB)
BuildID: 20141210075316
Gaia: 97873dca486abf4162a3345e71b375806937bdec
Gecko: 07a4ca3db40a
Version: 34.0 (2.1)
Firmware: V188-1
User Agent: Mozilla/5.0 (Mobile; rv:34.0) Gecko/34.0 Firefox/34.0

Device: Flame 2.0 (shallow flash 319MB)
BuildID: 20141210075212
Gaia: 4887744f873c8aa1ddadd9618e9b79dac259d27d
Gecko: dec2fdd8c4fe
Version: 32.0 (2.0)
Firmware: V188-1
User Agent: Mozilla/5.0 (Mobile; rv:32.0) Gecko/32.0 Firefox/32.0

Comment 4

[Joshua Mitchell (Inactive)]

nomming for 2.2 - Regression and Data-Loss

Comment 5

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

At comment 3 first sentence I meant to say this does not occur on 2.1 and *2.0.

Comment 6

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

b2g-inbound regression window:

Last Working Environmental Variables:
Device: Flame
BuildID: 20141010111807
Gaia: cdfa2f9943a729e7a682212a0ce4d24d965e041e
Gecko: 4e7ad11d7445
Version: 35.0a1 (2.2 Master)
Firmware: V188-1
User Agent: Mozilla/5.0 (Mobile; rv:35.0) Gecko/35.0 Firefox/35.0

First Broken Environmental Variables:
Device: Flame
BuildID: 20141010113806
Gaia: 0565fd0735bd353fda9b355c197d9f656907b1b4
Gecko: 4e40a2e933bc
Version: 35.0a1 (2.2 Master)
Firmware: V188-1
User Agent: Mozilla/5.0 (Mobile; rv:35.0) Gecko/35.0 Firefox/35.0

First Broken Gaia & Last Working Gecko - issue DOES repro
Gaia: 0565fd0735bd353fda9b355c197d9f656907b1b4
Gecko: 4e7ad11d7445

First Broken Gecko & Last Working Gaia - issue does NOT repro
Gaia: cdfa2f9943a729e7a682212a0ce4d24d965e041e
Gecko: 4e40a2e933bc

Gaia pushlog:
https://github.com/mozilla-b2g/gaia/compare/cdfa2f9943a729e7a682212a0ce4d24d965e041e...0565fd0735bd353fda9b355c197d9f656907b1b4

Caused by Bug 1027707.

Comment 7

[Joshua Mitchell (Inactive)]

broken by the patch to Bug 1027707 - can you take a look Gareth?

Comment 8

[Dylan Oliver [:doliver]]

triage: blocking, regression from AMD

Comment 9

[Gareth Aye [:gaye] (back from PTO)]

This one too :)

Comment 10

[Gareth Aye [:gaye] (back from PTO)]

This was fixed by changes landed on master tracked on bug 1109820