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

RESOLVED FIXED in 2.2 S5 (6feb)

Status

defect
RESOLVED FIXED
4 years ago
4 years ago

People

(Reporter: jbolton, Assigned: gaye)

Tracking

({regression})

unspecified
2.2 S5 (6feb)
ARM
Gonk (Firefox OS)

Firefox Tracking Flags

(blocking-b2g:2.2+, b2g-v2.0 unaffected, b2g-v2.1 unaffected, b2g-v2.2 fixed, b2g-master fixed)

Details

(Whiteboard: [2.2-flame-reduced-run], URL)

Attachments

(1 attachment)

(Reporter)

Description

4 years ago
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
(Reporter)

Updated

4 years ago
QA Whiteboard: [QAnalyst-Triage?]
Flags: needinfo?(dharris)
(Reporter)

Comment 1

4 years ago
Link to failed test case: https://moztrap.mozilla.org/manage/case/3863/
QAwanted for branch checks
QA Whiteboard: [QAnalyst-Triage?]
Flags: needinfo?(dharris)
Keywords: qawanted
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
QA Whiteboard: [QAnalyst-Triage?]
Flags: needinfo?(jmitchell)
Keywords: qawantedregression
nomming for 2.2 - Regression and Data-Loss
blocking-b2g: --- → 2.2?
QA Whiteboard: [QAnalyst-Triage?]
Flags: needinfo?(jmitchell)
At comment 3 first sentence I meant to say this does not occur on 2.1 and *2.0.
QA Contact: pcheng
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.
QA Whiteboard: [QAnalyst-Triage?]
Flags: needinfo?(jmitchell)
broken by the patch to Bug 1027707 - can you take a look Gareth?
Blocks: 1027707
QA Whiteboard: [QAnalyst-Triage?] → [QAnalyst-Triage+]
Flags: needinfo?(jmitchell) → needinfo?(gaye)
QA Contact: pcheng
triage: blocking, regression from AMD
blocking-b2g: 2.2? → 2.2+
(Assignee)

Updated

4 years ago
Assignee: nobody → gaye
Flags: needinfo?(gaye)
(Assignee)

Updated

4 years ago
Assignee: gaye → jlal
(Assignee)

Updated

4 years ago
Assignee: jlal → gaye
This one too :)
This was fixed by changes landed on master tracked on bug 1109820
Status: NEW → RESOLVED
Last Resolved: 4 years ago
Resolution: --- → FIXED
Target Milestone: --- → 2.2 S5 (6feb)
You need to log in before you can comment on or make changes to this bug.