989081 - [B2G][Calendar] Calendars are not automatically syncing after the initial sync

Status: VERIFIED DUPLICATE of bug 996384

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

Description

[demerick]

Attachment: logcat.txt

Summary (title) Field:
[B2G][Calendar] Calendars are not automatically syncing after the initial sync

Description:
Calendars are not automatically syncing after the user adds an account to the phone for the first time and Sync Calendar is not set to 'Manually'.

The calendar will process the initial sync, but will not sync according to the 15 minute or 30 minute setting.

Repro Steps:
1) Update a Buri to BuildID: 20140326000201
2) Launch Calendar from the home screen
3) Tap the 3 bars/drawer icon in the top left corner of the screen
4) Tap the '+' in the top right of the screen
5) Tap 'Google' and sign in to a google account
6) The user should be brought back to the 'Calendars' screen
7) Tap the settings/gear icon in the bottom right of the screen
8) Verify '15 min' is seen underneath 'Sync Calendar' and click done

Actual:
The Calendar app does not automatically sync after 15 minutes

Expected:
The Calendar app should automatically sync after 15 minutes

1.4 Environmental Variables:
Device: Buri 1.4 MOZ
BuildID: 20140326000201
Gaia: 7e705dd4718d528974d99ac31866318d7e201152
Gecko: 4889124accfa
Version: 30.0a2
Firmware Version: v1.2-device.cfg

Repro frequency: 100%
See attached: logcat

Notes: This also occurs if the phone is set to sync the calendar after 30 minutes

Comment 1

[demerick]

This issue also occurs on Buri 1.3 MOZ RIL

1.3 Environmental Variables:
Device: Buri 1.3 MOZ
BuildID: 20140326004002
Gaia: 812838ad0fabf51fa14435af562ddac6d26fa936
Gecko: ba97efb0da4b
Version: 28.0
Firmware Version: v1.2-device.cfg

Calendars are not automatically syncing after the initial sync when an account is added to the app. 

Note: This issue does not reproduce if the user resets or reboots the phone after adding the account to the calendar app.

Comment 2

[Jason Smith [:jsmith]]

There needs to be change to the calendar in question for syncing to occur. Did you make sure you did that here?

Comment 3

[demerick]

I did make sure to change the calendar after syncing to the phone, but I forgot to add that to the STR.

Updated STR:

1) Update a Buri to BuildID: 20140326000201
2) Launch Calendar from the home screen
3) Tap the 3 bars/drawer icon in the top left corner of the screen
4) Tap the '+' in the top right of the screen
5) Tap 'Google' and sign in to a google account, the user should be brought back to the 'Calendars' screen
6) Access Google Calendar for the account from the web on pc and add an event for tomorrow
7) Tap the settings/gear icon in the bottom right of the screen
8) Verify '15 min' is seen underneath 'Sync Calendar' and click done - wait 15 minutes

Comment 4

[Jason Smith [:jsmith]]

Does this happen on 1.1? Maybe something on the server side changed that broke us client side...

Comment 5

[Lionel Mauritson]

Using a 1.1 Buri:
After connecting to a Google calendar, then adding another event online and waiting ~15 minutes, the new event appeared on the device calendar as expected.

1.1 Environmental Variables:
Device: Buri 1.1 MOZ
BuildID: 20140331041208
Gaia: 44a2ddf63373f8e95c784faf4ed4d60081699c61
Gecko: 170d87349060
Version: 18.0
Firmware Version: v1.2-device.cfg

Comment 6

[Jason Smith [:jsmith]]

I can reproduce on 1.3. Weird - we haven't changed much in the calendar app, so maybe a gecko regression caused this?

Comment 7

[Jason Smith [:jsmith]]

FYI to Gareth - I did notice that manual sync works fine here. Only periodic sync isn't working.

Comment 8

[Lionel Mauritson]

Attachment: logcat_20140401_0916_calendar.txt

After comment 6 I had someone else test this, and we found that the issue is intermittent. The first time I tried on 1.1 it worked fine, second time as well, and only after around 10 minutes. I had someone else try on their device and it did not update after 15, so we both tried a few more times with mixed results. It seems that the timer is inaccurate; though we are not certain when it starts counting down the calendar appears to update anywhere within 10 and 25 minutes of setting up the calendar, with subsequent updates appearing more regularly.

Comment 9

[Jason Smith [:jsmith]]

(In reply to Lionel Mauritson from comment #8)
> Created attachment 8400066 [details]
> logcat_20140401_0916_calendar.txt
> 
> After comment 6 I had someone else test this, and we found that the issue is
> intermittent. The first time I tried on 1.1 it worked fine, second time as
> well, and only after around 10 minutes. I had someone else try on their
> device and it did not update after 15, so we both tried a few more times
> with mixed results. It seems that the timer is inaccurate; though we are not
> certain when it starts counting down the calendar appears to update anywhere
> within 10 and 25 minutes of setting up the calendar, with subsequent updates
> appearing more regularly.

This is not the same bug. This bug deals with the fact that periodic sync is always failing, not the fact that the timer is inaccurate for periodic sync.

Comment 10

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

Can we get a regression window here?

Comment 11

[Lionel Mauritson]

Is there a way to speed up the calendar sync time without invalidating the test? Currently the fastest I can get it to is 15 minutes, plus the time it takes to flash and set up the calendar.

Comment 12

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

Lionel - Hey do you know how to apply a patch to gaia in git?

Comment 13

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

Attachment: monkey.patch

Comment 14

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

This patch may help if you can apply this at the different points in the bisection using |git apply|. If it applies cleanly, it makes it so that anytime you change the syncFrequency (ie anytime you change from 15 min => 30 min or 30 min => 15 min) it will actually change the periodic sync to happen every one minute.

Comment 15

[Jason Smith [:jsmith]]

(In reply to Gareth Aye [:gaye] from comment #12)
> Lionel - Hey do you know how to apply a patch to gaia in git?

If you put up a github branch with your patch, then I can have someone test with your patch.

Comment 16

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

Wonderful! Thanks :jsmith!! https://github.com/gaye/gaia/tree/game-the-syncfrequency

Comment 17

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

Note again that the change that I made makes it so that changing the syncFrequency sets it to 1 minute. You still have to change it though :P

Comment 18

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

This will only work btw to check if it's a gecko regression since going back to a previous gaia version will get rid of my patch

Comment 19

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

In my investigation so far, I have found (I think) that the alarm that the calendar sets via mozAlarms#add tied to performing a sync when the alarm fires is not being fired. Not sure why that would be the case since mcav thinks clock isn't experiencing any trouble with mozAlarms...

Comment 20

[Lionel Mauritson]

Will the patch work if I need to go back as far as 1.2? This issue appears to be fairly old. If still valid, or even if just to learn for the sake of it, I could use some pointers on how to apply this properly.

Comment 21

[Jason Smith [:jsmith]]

(In reply to Gareth Aye [:gaye] from comment #19)
> In my investigation so far, I have found (I think) that the alarm that the
> calendar sets via mozAlarms#add tied to performing a sync when the alarm
> fires is not being fired. Not sure why that would be the case since mcav
> thinks clock isn't experiencing any trouble with mozAlarms...

Any chance you could turn that into a reduced test case with mozAlarms? That would help diagnose this bug quicker to establish that this is a gecko bug.

Comment 22

[Jason Smith [:jsmith]]

(In reply to Lionel Mauritson from comment #20)
> Will the patch work if I need to go back as far as 1.2? This issue appears
> to be fairly old. If still valid, or even if just to learn for the sake of
> it, I could use some pointers on how to apply this properly.

How far have you gone back so far?

Comment 23

[Lionel Mauritson]

I'm running in to a problem where I don't know which bug is occurring since there is no way I know of to tell.
Sometimes the calendar takes a very long time to update (sometimes over an hour) but the same build inconsistently updates under 15 minutes some of the time, and sometimes it appears to never update, but I don't know if it eventually will if I just wait a little longer. This is the reason I originally thought these varying severity levels of the same issue.

I am not certain how useful this info is as I don't know how accurate it is, but this is where I've gotten to so far:

Maybe occurs (Did not update within 30 minutes)

1.3 Environmental Variables:
Device: Buri 1.3 MOZ
BuildID: 20131010040202
Gaia: 959ac2f692d85072ffdc3d16a041b5bf4735ae59
Gecko: aa986b6ce882
Version: 27.0a1
Firmware Version: v1.2-device.cfg

Maybe doesn't occur (Eventually updated after 2 hours)

1.2 Environmental Variables:
Device: Buri 1.2 MOZ
BuildID: 20140327004001
Gaia: 539a25e1887b902b8b25038c547048e691bd97f6
Gecko: 41acea9beff3
Version: 26.0
Firmware Version: v1.2-device.cfg

Comment 24

[Jason Smith [:jsmith]]

Sounds like getting a window here is going to be difficult, so clearing the window request. Let's try a different approach via working with someone who owns mozAlarms to diagnose this bug.

Andrew - Can you get someone to weigh in here to see if this is a gecko problem with mozAlarms?

Comment 25

[Andrew Overholt [:overholt]]

Gene would be the best person to investigate.

Comment 26

[Gene Lian (I already quit Mozilla)]

I'm have a business trip this week. Will take a look on this when I'm available.

The only recent changes on mozAlarms are made by Alexandre:

http://hg.mozilla.org/mozilla-central/filelog/8883360b1edb/dom/alarm/AlarmsManager.js

If this issue is really related to mozAlarm, I'm suspecting we have to remove the following check:

1.12 +    // SystemPrincipal documents do not have any origin.
1.13 +    // Reject them for now.
1.14 +    if (!principal.URI) {
1.15 +      return null;
1.16 +    }

Hi, Alexandre, we're not yet sure if it's really caused by mozAlarm (I'll investigate this when I'm available), just a quick needinfo to you to see could it be or not?

Comment 27

[Alexandre Poirot [:ochameau]]

It really looks like what I fixed in bug 980682, which is only specific to firefox30+,
as it fixed a regression introduced by bug 963258 (which landed only in firefox30).
So if that happen on 1.3, it isn't because of this modification as none of these bugs/patches are in 1.3.

Comment 28

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

After some more investigation, I now know that there are valid calendar bugs. One is that setting up a google account somehow purges calendar's periodic sync alarms from the system's alarms database. Another is that updating Yahoo! calendars (either manually or via periodic sync) is broken. Fortunately, I know that periodic sync is not generally broken since Zimbra calendars update just fine :).

Comment 29

[Gene Lian (I already quit Mozilla)]

\^O^/ Thanks Gareth!

Comment 30

[Jason Smith [:jsmith]]

Gareth - Is this fixed with the landing of bug 996384?

Comment 31

[Jason Smith [:jsmith]]

(In reply to Jason Smith [:jsmith] from comment #30)
> Gareth - Is this fixed with the landing of bug 996384?

Dylan answered this in a different bug - it should be, but we should confirm that.

QA Wanted to confirm this is fixed on trunk.

Comment 32

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

(In reply to Jason Smith [:jsmith] from comment #31)
> 
> QA Wanted to confirm this is fixed on trunk.

Confirmed that this is fixed on today's master build.
The calendar correctly updated within 15th minutes or within 30th minutes, when set to update every 15 minutes or 30 minutes, respectively.

Device: Buri 2.0 MOZ
BuildID: 20140418040202
Gaia: 375d87bfef8a5d7135f139da8c17f237b990d3f5
Gecko: 7fe3ee0cf8be
Version: 31.0a1
Firmware Version: v1.2-device.cfg