1042422 - [B2G][Calendar] Refreshing calendar causes events to be pulled down for accounts that are disabled

Status: VERIFIED FIXED

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

Description

[Jordan de Geus(JordanD)]

Attachment: logcat_calendar.txt

Description:
When users disable a calendar account and add an event to their calendar via the website, upon selecting refresh on their device, the user will see the even be pulled down. This occurrs for Google, Yahoo, and Caldav accounts.

Repro Steps:
1) Update a Flame to 20140721000201
2) Launch Calendar> drawer icon> settings> Add an account
3) Select drawer icon> disable account
4) Navigate to your accounts website and add an event to your calendar
5) On your device, select the drawer icon and select Refresh
6) Observe account pulls newly added event to the device.

Actual:
Users calendars will pull down events for accounts that have been disabled.


Expected:
Disabled accounts do not pull down events

Environmental Variables:
Device: Flame 2.0
Build ID: 20140721000201
Gaia: 8cb1a949f2e9650bb2c5598e78a6f24a58bbaf97
Gecko: 4bd4b0ae7bbe
Version: 32.0a2 (2.0)
Firmware Version: v122
User Agent: Mozilla/5.0 (Mobile; rv:32.0) Gecko/32.0 Firefox/32.0

Repro frequency: 5/5
Link to failed test case:
See attached: Logcat and Video
Logcat_calendar.txt - http://youtu.be/n9nUhO4RXBY

Comment 1

[Jordan de Geus(JordanD)]

This issue DOES OCCUR on Flame 2.1(273mb), Flame 2.0(512mb), Buri 2.1, Buri 2.0

Actual: Users will see disabled calendar accounts pull down events from their calendar

Flame 2.1 (273mb)
Environmental Variables:
Device: flame 2.1
BuildID: 20140721062116
Gaia:
Gecko: 0dc711216018
Version: 33.0a1
Firmware Version: v122
User Agent: Mozilla/5.0 (Mobile; rv:33.0) Gecko/33.0 Firefox/33.0

Buri 2.1

Environmental Variables:
Device: Buri Master
BuildID: 20140721062116
Gaia: Unknown
Gecko: 0dc711216018
Version:  33.0a1
Firmware Version: v1.2-device.cfg
User Agent: Mozilla/5.0 (Mobile; rv:33.0) Gecko/33.0 Firefox/33.0

Flame 2.0 (512mb) 

Environmental Variables:
Device: Flame 2.0
Build ID: 20140721000201
Gaia: 8cb1a949f2e9650bb2c5598e78a6f24a58bbaf97
Gecko: 4bd4b0ae7bbe
Version: 32.0a2 (2.0)
Firmware Version: v122
User Agent: Mozilla/5.0 (Mobile; rv:32.0) Gecko/32.0 Firefox/32.0

Buri 2.0

Environmental Variables:
Device: Buri 2.0
Build ID: 20140721003002
Gaia: 8cb1a949f2e9650bb2c5598e78a6f24a58bbaf97
Gecko: 4bd4b0ae7bbe
Version: 32.0a2 (2.0) MOZ
Firmware Version: v1.2device.cfg
User Agent: Mozilla/5.0 (Mobile; rv:32.0) Gecko/32.0 Firefox/32.0

--------------------------------------------------------------------------------------

This issue DOES NOT occur on Flame 1.4 (273mb) and Buri 1.4

Actual: Users are NOT seeing calendar events pulled down for disabled accounts.

Flame 1.4

Environmental Variables:
Device: Flame 1.4
Build ID: 20140721000201
Gaia: 621d152f89347c79619aa909ad62cc2ac9d3ab5b
Gecko: 83b7be7fb33f
Version: 30.0 (1.4)
Firmware Version: v122
User Agent: Mozilla/5.0 (Mobile; rv:30.0) Gecko/30.0 Firefox/30.0

Buri 1.4 

Environmental Variables:
Device: Buri 1.4
Build ID: 20140721000201
Gaia: 621d152f89347c79619aa909ad62cc2ac9d3ab5b
Gecko: 83b7be7fb33f
Version: 30.0 (1.4)
Firmware Version: v1.2device.cfg
User Agent: Mozilla/5.0 (Mobile; rv:30.0) Gecko/30.0 Firefox/30.0

Comment 2

[Jordan de Geus(JordanD)]

Forgot to attach link to failed test case: 
https://moztrap.mozilla.org/manage/case/2464/

Comment 3

[KTucker [:KTucker][Inactive 3/4/2016]]

[Blocking Requested - why for this release]:

Since this is a regression from 1.4 and the user purposely disabled the account it should not be pulling calendar events. This is unwanted behavior. Nominating 2.0?

Comment 4

[Miller Medeiros [:millermedeiros]]

so, this happens because on 1.4 we used CSS to hide the events from the disabled calendars and now we just use JavaScript to filter the data before displaying. Since the event is added afterwards it is using a different code path (each view have listeners for when events are added/removed and handle the view update).. I'm going to change the code to avoid dispatching add/remove events from hidden calendars.

PS: we always fetch the data and keep the events on the database, the "disabled account" is just an UI thing, it doesn't change the sync behavior.

Comment 5

[Miller Medeiros [:millermedeiros]]

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

Comment 6

[Joshua Mitchell (Inactive)]

Removing regression-window wanted tag, comment 5 indicates the problem has already been identified and tentatively fixed with a patch; no sense in wasting resources on a window at this point. :)

Comment 7

[Miller Medeiros [:millermedeiros]]

Gareth, I updated the patch to include the marionette test that you wanted so much.

PS: this patch will also fix the Bug 1031182 since that was necessary (otherwise we would introduce a worse regression with this patch where events would not show up on initial load).

Comment 8

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

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

LGTM! Thanks Miller :)

Comment 9

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

https://github.com/mozilla-b2g/gaia/commit/166a35556ef4e4dd48a91a4773a1bec674869e55 landed on master

Comment 10

[Ryan VanderMeulen [:RyanVM]]

v2.0: https://github.com/mozilla-b2g/gaia/commit/6189bb8c3573a10863ac290054eab8fe141d8125

Comment 11

[Edward Chen[:edchen]]

[Environment]
Gaia      3584b2723412ed3299c6761f465885d80651c87e
Gecko     https://hg.mozilla.org/mozilla-central/rev/e7806c9c83f3
BuildID   20140820160201
Version   34.0a1
ro.build.version.incremental=94
ro.build.date=Tue May 20 09:29:20 CST 2014


[Result]
PASS