Closed Bug 1018834 (calendar-alarm-spam) Opened 11 years ago Closed 7 years ago

Calendar issues system notifications for events without reminders

Categories

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

All
Gonk (Firefox OS)
defect
Not set
normal

Tracking

(blocking-b2g:-, b2g-v1.3 affected)

RESOLVED WONTFIX
blocking-b2g -
Tracking Status
b2g-v1.3 --- affected

People

(Reporter: ladamski, Unassigned)

References

Details

Attachments

(8 files)

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.
blocking-b2g: --- → 2.0?
Kate, can you try to reproduce this one?
Flags: needinfo?(kglazko)
Keywords: qawanted
Yes, I will do that right now.
Flags: needinfo?(kglazko)
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..)
QA Contact: kglazko
blocking-b2g: 2.0? → 2.0+
Keywords: qawanted
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
Adding QA Wanted to also check if this happens on 1.4.
Keywords: qawanted
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
Keywords: qawanted
What about 1.3?
Keywords: qawanted
Assignee: nobody → mmedeiros
Target Milestone: --- → 2.0 S4 (20june)
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
Keywords: qawanted
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:example@gmail.com 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:example@gmail.com 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
See Also: → 474983, 566645
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.
Keywords: qawanted
Tried now, with an old Yahoo! account of mine. Problem does not carry over to Yahoo!. I will check Zimbra soon.
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.
Assignee: mmedeiros → nobody
Target Milestone: 2.0 S4 (20june) → ---
(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?
Flags: needinfo?(gaye)
This happens with Zimbra not Google. This also doesn't happen with Zimbra and any other client I've used.
"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?
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.
Keywords: qawanted
Sorry that was confusing. I meant that I don't have this problem with Zimbra when using any other client, only FFOS.
If this is not a regression, why is it a 2.0 blocker?
(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.
blocking-b2g: 2.0+ → -
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.
Attached image reminder.png
(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.
Flags: needinfo?(gaye)
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.
Hi all, this bug is not a dupe, but looks like it may be related: https://bugzilla.mozilla.org/show_bug.cgi?id=1032572
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).
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!
Attachment #8449410 - Flags: feedback?(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 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
Attachment #8449410 - Flags: feedback?(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.
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.
Attached image screenshot
Attached image screenshot
Attached image 2014-07-10-15-02-10.png
Attached image 2014-07-10-15-02-24.png
Attached image reminder2.png
Attached image reminder3.png
Assignee: nobody → gaye
Summary: Calendar adds reminders to existing events with no reminders set → Calendar issues system notifications for events without reminders
Alias: calendar-alarm-spam
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).
FWIW the BugzillaJS extension is really nice for viewing image attachments inline, and other features.
Assignee: gaye → nobody
See Also: → 925580
Firefox OS is not being worked on
Status: NEW → RESOLVED
Closed: 7 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: