995827 - Setting up a Google calendar account purges periodic sync alarms from mozAlarms

Status: VERIFIED DUPLICATE of bug 996384

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

Description

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

When we launch calendar, we put an alarm in mozAlarms. When that alarm fires, we do a periodic sync and add another alarm to mozAlarms (to continue periodic syncing). For some reason, setting up a Google account removes the periodic sync alarms from the mozAlarms database which makes it seem like periodic syncing calendar accounts is broken. In reality,

(1) this is a Google-only issue and
(2) users can resume periodic sync by changing the sync interval which will add another entry to the mozAlarms database

Comment 1

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

Attachment: Link to Github pull-request: https://github.com/mozilla-b2g/gaia/pull/18265

The authorial intent behind calling clearBrowserData() before launching the browser for oauth was to clear the "child" browser's cookies before sending the user to the oauth provider. Unfortunately, WebappsApplication#clearBrowserData does more than just clear the cookies. It also purges the alarms we've scheduled via the alarms api which breaks periodic sync. Perhaps we need a more granular api in order to clear the cookies (which will enable a fresh auth interaction) without clearing the alarms.

I've added a patch (in the meantime) that doesn't make a call to clearBrowserData(). This is not necessarily a good thing. This will probably complicate (if not break) the scenario where a user has multiple Google accounts though I have not yet tested. However, this does fix the periodic sync issue.

Comment 2

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

Pinging fabrice and bent regarding WebappsApplication#clearBrowserData. In my use case, I would like to clear the cookies in the "child" browser my app launches without clearing the alarms I've scheduled via the alarm manager. Can we make that happen? If so, can we do it for 1.3?

Comment 3

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

^^ Blocking a 1.3 blocker

Comment 4

[Miller Medeiros [:millermedeiros]]

one thing I suggested on IRC as a temporary hack is to store the current alarms and than restore them later.. but that will surely increase code complexity and can cause new bugs (race conditions, alarm might trigger during the account setup, app might crash/close during process, ...) - so I agree with :gaye that best solution would be if the system allowed some way to just clean the cookies.

Comment 5

[[:fabrice] Fabrice Desré]

Yes, I think that's a bug in several observers of webapps-clear-data. They should honor the browserOnly flag that is set to true at https://mxr.mozilla.org/mozilla-central/source/dom/apps/src/Webapps.jsm#3927 but they don't (see https://mxr.mozilla.org/mozilla-central/source/dom/alarm/AlarmService.jsm#510 for the alarms case). We set it to false when uninstalling an app to make sure we cleanup everything.

Ben, do you agree?

Comment 6

[Ben Turner (not reading bugmail, use the needinfo flag!)]

(In reply to Fabrice Desré [:fabrice] from comment #5)
> Ben, do you agree?

Sounds right to me

Comment 7

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

So then is someone available to fix this for 1.3?

Comment 8

[Miller Medeiros [:millermedeiros]]

Comment on attachment 8405939 [details] [review]
Link to Github pull-request: https://github.com/mozilla-b2g/gaia/pull/18265

lets avoid hacks and wait for the system fix!

Comment 9

[Jason Smith [:jsmith]]

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

Comment 10

[Dylan Oliver [:doliver]]

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

We need to test & confirm but yes it should be (and bug 989081 too).

Comment 11

[Jason Smith [:jsmith]]

(In reply to Dylan Oliver [:doliver] (PTO until 23 April) from comment #10)
> (In reply to Jason Smith [:jsmith] from comment #9)
> > Gareth - Is this fixed with the landing of bug 996384?
> 
> We need to test & confirm but yes it should be (and bug 989081 too).

ok - I'll flag bug 989081 to have someone retest

Comment 13

[Edward Chen[:edchen]]

bug 996384 has been fixed.