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

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

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

[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?

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.

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. :)

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 on attachment 8461303 [details] Link to Github pull-request: https://github.com/mozilla-b2g/gaia/pull/22092 LGTM! Thanks Miller :)

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

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

[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