1018834 - (calendar-alarm-spam) Calendar issues system notifications for events without reminders

Status: RESOLVED WONTFIX

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

Description

[Lucas Adamski [:ladamski]]

Flame 2.0 recent builds, including 20140529.

When syncing events from the server, reminders are added to events that have no reminders which then are propagated back to the server.  This is extremely annoying as it makes it impossible to have events without a reminder.  It should only add the default reminder when adding new events locally.

Comment 1

[Dylan Oliver [:doliver]]

Kate, can you try to reproduce this one?

Comment 2

[Kate Glazko]

Yes, I will do that right now.

Comment 3

[Kate Glazko]

Confirmed on Flame 2.0, Platform Version 32.0a1, Build ID 2014060272051.

Steps to Recreate:
1.) Open Calendar
2.) Create an event, set 'None' for reminders.
3.) Verify that there is no bell next to your event on the month view of the day.
3.) Go to the Slide out Drawer and hit the 'refresh' button on the bottom right.
4.) You will hear and see the reminder, and a bell will now appear next to your event.

(Note: If you are using a personal calendar, reminders will be generated on your computer/other devices as well. For example, I am using a Gmail account and my computer just sent me three friendly reminders from the events that I created testing this..)

Comment 4

[Kate Glazko]

Sorry, should've included this on my last comment:

Gaia      ebbc9c33f3500b1b70a70899b0ed0d0ca1d1417d
Gecko     https://hg.mozilla.org/mozilla-central/rev/6a984e21c2ca
BuildID   20140602072051
Version   32.0a1
ro.build.version.incremental=eng.cltbld.20140527.072313
ro.build.date=Tue May 27 07:23:22 EDT 2014

Comment 5

[Jason Smith [:jsmith]]

Adding QA Wanted to also check if this happens on 1.4.

Comment 6

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

Issue is reproducible on Flame 1.4. After adding a google calendar event with Reminder set to None, refreshing/re-sync'ing the calendar automatically adds reminder to the event.

The workaround is to edit the event again, set reminder to none, and re-sync'ing the calendar will no longer add reminder to the event.

Tested on:
Device: Flame
Build ID: 20140606000204
Gaia: 183efb374be1bcbf92f1fb3d0212a68b564a6d3e
Gecko: 960c48b5a5fa
Version: 30.0 
Firmware Version: v10G-2
User Agent: Mozilla/5.0 (Mobile; rv:30.0) Gecko/30.0 Firefox/30.0

Comment 7

[Jason Smith [:jsmith]]

What about 1.3?

Comment 8

[Cody Roesch [:croesch]]

I have verified that this bug DOES exist on V1.3. Testing with an OpenC device, I created a calendar event with no alarm with a gmail account. Resync'd and a 30 minute alarm got added to the event.

Environmental Variables:
Device: Open_C 1.3
Build ID: 20140505052400
Gaia: Unknown Git commit; build date shown here.
Gecko: Unknown
Version: 28.0 (1.3) 
Firmware Version: P821A10V1.0.0B06_LOG_DL

Comment 9

[Miller Medeiros [:millermedeiros]]

Google adds the default reminders for events created elsewhere:

### data sent when creating the event

BEGIN:VCALENDAR
PRODID:-//Mozilla//FirefoxOS
VERSION:2.0
BEGIN:VEVENT
UID:085dd7ec-738c-4ac3-96d4-397fc6deff16
SUMMARY:Phone home
DESCRIPTION:
LOCATION:
SEQUENCE:1
DTSTART:20140611T230000Z
DTEND:20140612T000000Z
END:VEVENT
END:VCALENDAR


### data received during sync

BEGIN:VCALENDAR
PRODID:-//Google Inc//Google Calendar 70.9054//EN
VERSION:2.0
CALSCALE:GREGORIAN
X-WR-CALNAME:[e-mail]
X-WR-TIMEZONE:America/Sao_Paulo
BEGIN:VEVENT
DTSTART:20140611T230000Z
DTEND:20140612T000000Z
DTSTAMP:20140611T221727Z
UID:085dd7ec-738c-4ac3-96d4-397fc6deff16
CREATED:20140611T221727Z
DESCRIPTION:
LAST-MODIFIED:20140611T221727Z
LOCATION:
SEQUENCE:1
STATUS:CONFIRMED
SUMMARY:Phone home
TRANSP:OPAQUE
BEGIN:VALARM
ACTION:EMAIL
DESCRIPTION:This is an event reminder
SUMMARY:Alarm notification
ATTENDEE:mailto:[e-mail]
TRIGGER:-P0DT0H10M0S
END:VALARM
BEGIN:VALARM
ACTION:DISPLAY
DESCRIPTION:This is an event reminder
TRIGGER:-P0DT0H30M0S
END:VALARM
END:VEVENT
END:VCALENDAR

I also found a couple old bugs on bugzilla describing same issue on other products (Bug 474983 and Bug 566645), a few users complaining about iOS calendar app (unsure if newer versions still have the same issue) and a report to Google CalDAV as well (https://code.google.com/p/google-caldav-issues/issues/detail?id=51)

there is probably a way to bypass the default behavior since Google doesn't add the default reminders to events created from Lightning 2.6.5

Comment 10

[Dylan Oliver [:doliver]]

Kate, can you try this again with Zimbra & Yahoo calendars to confirm if this problem is limited to Google? It looks like all of the reproductions in comments 3,6,8 are based on Google accounts.

Comment 11

[Kate Glazko]

Tried now, with an old Yahoo! account of mine. Problem does not carry over to Yahoo!. I will check Zimbra soon.

Comment 12

[Miller Medeiros [:millermedeiros]]

and it looks like Lightning still uses the old Atom Google Calendar API (http://hg.mozilla.org/comm-central/file/9e17f6ef6620/calendar/providers/gdata/components/calGoogleUtils.js#l481) maybe that's why they can bypass the default reminders..

I also saw that on the new REST API they have the option to bypass the default reminders (https://developers.google.com/google-apps/calendar/v3/reference/events/insert#reminders.useDefault) but no information about the CalDAV API.

so I'm not sure what to do now. Almost marking this as WONTFIX since it's not our fault.

Comment 13

[Dylan Oliver [:doliver]]

(In reply to Miller Medeiros [:millermedeiros] from comment #12)
> so I'm not sure what to do now. Almost marking this as WONTFIX since it's
> not our fault.

I don't think we should wontfix -- it's useful to leave it open here for people to find/dupe. But probably it doesn't make sense to block 2.0 on it.

Gareth, can you follow up with your Google CalDAV contact to see if there's any hope to get this resolved in the near future or if there's any other workaround?

Comment 14

[Lucas Adamski [:ladamski]]

This happens with Zimbra not Google.  This also doesn't happen with Zimbra and any other client I've used.

Comment 15

[Kate Glazko]

"This happens with Zimbra not Google.  This also doesn't happen with Zimbra and any other client I've used."

Wait, it happens with Zimbra and doesn't happen with Zimbra?

Comment 16

[Joshua Mitchell (Inactive)]

Removing QA-Wanted flag - this issue seems to have been checked for Yahoo and Zumbra; we just need to clarify what the actual Zimbra results were.

Comment 17

[Lucas Adamski [:ladamski]]

Sorry that was confusing.  I meant that I don't have this problem with Zimbra when using any other client, only FFOS.

Comment 18

[Dietrich Ayala (:dietrich)]

If this is not a regression, why is it a 2.0 blocker?

Comment 19

[bhavana bajaj [:bajaj]]

(In reply to Dietrich Ayala (:dietrich) from comment #18)
> If this is not a regression, why is it a 2.0 blocker?

Not sure why. But agree on minusing this here, given 1.3 is affected unless folks have a strong reason to block on this feel free to renom. But given the existing blocker guidelines we would not block on this. We would consider an uplift if fixed by FC depending on the risk here.

Comment 20

[Lucas Adamski [:ladamski]]

This is a really annoying problem.  Are we really ok shipping a product that forces users to have reminders on every single meeting?  I'm also having a related problem that we're creating reminders for some arbitrarily long time before the actual meeting, resulting in reminders that pop up 3 weeks ago.  That maybe a separate bug, but I'm attaching the screenshot here in case its related.

Comment 21

[Lucas Adamski [:ladamski]]

Attachment: reminder.png

Comment 22

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

(In reply to Lucas Adamski [:ladamski] (plz needinfo) from comment #20)
> This is a really annoying problem.  Are we really ok shipping a product that
> forces users to have reminders on every single meeting?  I'm also having a
> related problem that we're creating reminders for some arbitrarily long time
> before the actual meeting, resulting in reminders that pop up 3 weeks ago. 
> That maybe a separate bug, but I'm attaching the screenshot here in case its
> related.

I agree that this is annoying and, while I can't speak to how acceptable or unacceptable of a user experience this is, I will give some context and say two things related to my longer-term, technical vision for calendar.

<context>

As far as timing and scope go, it's been about 6 months since I started working on calendar full-time (the level of maintenance work that needed to be done for the marionette js became reasonable background work around Jan/Feb this year). This is also around when Miller joined and started working on calendar and when James moved on from gaia to look at other problems with Mozilla's testing infrastructure. In that time, we have together shipped the visual refresh, built out a great suite of ui + server interop tests, and fixed a large number of ui, polish, and l10n issues.

We started from a place of pretty overwhelming technical debt since James and I (from last May until the end of the year) were focusing primarily on gaia's testing infrastructure. Most other app teams spent last year recovering from the pre v1.0.1 push whereas the calendar team is still working off a lot of our technical debt today. Calendar is in worse shape nowadays because James and I put half a [crazy] year's worth of work into improving gaia rather than improving calendar. I assumed we would get more hacking help with testing infrastructure than we did from other people in gaia since we built something of a community resource, but we didn't. People were more interested in writing their application logic. That's okay but my hope is that it helps give some insight into why parts of our 2.0 calendar release like this bug are a bit "lackluster".

We are taking big strides nowadays toward a happier technical place in calendar. For instance in June I wrote ~12k lines of dav client code with nearly 100% test coverage which is a huge improvement over what we had before. Once this lands in calendar, there will be many fewer sync issues and fixing the ones that we'll have will be much more tractable. This is going to help us tremendously with future feature work like invitations / scheduling and also with future perf work like lowering our resource usage with the new, smarter rfc 6578 webdav sync. The services / sync team is also planning on using my work for various bits related to cloud contacts backup (since the client library supports carddav) and calendar will benefit from the virtuous cycles that arise when you share code.

</context>

So with that in mind...

(1) The periodic sync and alarms/notifications parts of the calendar codebase were tacked on without much design or testing at the end of v1.0.1 by someone who no longer contributes to Mozilla projects AFAICT. FWIW, we couldn't have [at the time] written any very deep tests that would catch a lot of these issues that are popping up since the infrastructure to write realistic app tests that exercise interactions with things like mozAlarms, Notification, etc simply didn't exist before ~1.3. These calendar app code paths are absolutely a mess and in need of an overhaul. We have a lot of refactoring work (including alarm / periodic sync stuff) planned for 2.1 and I am not sure that the remaining 2.0 sprint is the right time to tackle this. I'm also not sure that it isn't, but I want at least open up some of the considerations.

(2) It's also worth noting that the sync / services team is currently working on a sync web api that will allow apps to opt into being woken up at an interval when favorable networking conditions are available. If we put off fixing some of these alarm / reminder issues, we will be able to rip out all of the calendar code that puts alarms in the system's alarms database to schedule wakeups and dogfood the sync team's platform work.

I cast my vote for not fixing this in 2.0 unless there's a very simple and low-effort patch that can be applied to our alarms / periodic sync business logic. My vote is coming from a place of wanting to look at the larger, technical picture. But the larger, technical picture isn't the only one and it has to be weighed against other concerns like 2.0 ux, so I would understand if people felt we *really* needed to fix this asap.

Comment 23

[Lucas Adamski [:ladamski]]

I'm really glad you're stepping up to own Calendar and obviously feel a strong sense of ownership around it, that's great. I'm also sure the code here was cobbled together in the 1.0.1 timeframe, as is much of the code in the project.  However, unless my Zimbra config is singularly endowed with a magical ability to surface bugs, these issues are not due to lack of automation but lack of daily usage on actual mobile devices for several releases now.  The fix in this case is probably as simple as just not adding a default reminder to meetings that are created via sync vs locally.  I really do use my Flame as my only mobile phone, but if calendaring and email aren't usable by the time we're done with 2.0 I'll be handing mine back.

Comment 24

[Kate Glazko]

Hi all, this bug is not a dupe, but looks like it may be related: https://bugzilla.mozilla.org/show_bug.cgi?id=1032572

Comment 25

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

Curiously, I wrote an integration test against our test (http://radicale.org/) caldav server and this issue does not reproduce - see https://github.com/mozilla-b2g/gaia/blob/master/apps/calendar/test/marionette/server_test.js#L196. The test

1. sets up a caldav account against the local radicale instance,
2. creates a few issues with different properties (including one that doesn't have any alarms),
3. persists the created events to the local radicale instance,
4. deletes the radicale account from the calendar app,
5. sets up the account again,
6. checks to make sure that all of the created events got synchronized back to the calendar app without losing (or in this case adding) any additional data

I'm going to go ahead and point the test to my zimbra account to see if we can't figure out what's going on here. My limited investigation so far does suggest that the issue is more complicated (and perhaps has to do with Zimbra's caldav implementation).

Comment 26

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

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

Hi Lucas,

I pointed a test that AFAICT should reproduce your issue to my own Zimbra account and the issue did not reproduce.

This means that the events that you have which are having reminders wrongly added to them are indeed special (perhaps "magical" : ). Just so I understand the situation completely, where are you creating these events without alarms? What I have proven here is that if I create an event with no reminders on a Zimbra calendar from the fxos calendar, persist them to zimbra, and then sync them back to the device, they don't pick up any extraneous reminders.

Hope this helps!

Comment 27

[Lucas Adamski [:ladamski]]

So I tried reproducing this on Friday and it no longer was for me either.  Maybe a Zimbra update fixed something, I don't know.  I do know I'm not crazy as I had a ton of reminders on Thu and even showed the phone to the QA folks in MV. :) 

I'll keep testing again and if it resurfaces (with a clear STR) I'll drop in again.

FWIW it was a very simple STR.  If I had a new meeting or took an existing meeting and removed the reminder (via Zimbra web interface or iCal), once the phone synce'd again it would re-add the reminder then sync back to the server, complete with a weird timeshift (i.e. reminders were being set for 20 days, some random hours and seconds before each meeting).

Comment 28

[Lucas Adamski [:ladamski]]

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

Test looks fine but I can't repro the issue currently

Comment 29

[Lucas Adamski [:ladamski]]

Any chance this was related to a time-warp bug?  I noticed a bunch of platform issues with geolocation as well at the same time, and both seem to have gone away recently.  Maybe purely coincidental.

Comment 30

[Lucas Adamski [:ladamski]]

OK it just happened again.  I've attached some screenshots that show what happened, but let me know if I can provide something useful for debugging purposes.  No particular STR, I had my desktop open for a while and then at some point my phone goes crazy with 74 notifications.

Comment 31

[Lucas Adamski [:ladamski]]

Attachment: screenshot

Comment 32

[Lucas Adamski [:ladamski]]

Attachment: screenshot

Comment 33

[Lucas Adamski [:ladamski]]

Attachment: 2014-07-10-15-02-10.png

Comment 34

[Lucas Adamski [:ladamski]]

Attachment: 2014-07-10-15-02-24.png

Comment 35

[Lucas Adamski [:ladamski]]

Attachment: reminder2.png

Comment 36

[Lucas Adamski [:ladamski]]

Attachment: reminder3.png

Comment 38

[Lucas Adamski [:ladamski]]

To be clear the bug isn't just about spam notifications, it actually adds a notification to the meeting which is then propagated to the server (hence the iCal screenshot above).

Comment 39

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

Ah I only looked at attachment 8454058 [details]

Comment 40

[Lucas Adamski [:ladamski]]

FWIW the BugzillaJS extension is really nice for viewing image attachments inline, and other features.

Comment 41

[BMO Automation]

Firefox OS is not being worked on