1110183 - Displayed reminders can be improperly snoozed or duplicated when the calendar is refreshed

Status: RESOLVED FIXED

(Calendar :: Alarms, defect, P2)

Description

[thE_iNviNciblE]

User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:35.0) Gecko/20100101 Firefox/35.0
Build ID: 20141208150535

Steps to reproduce:

Sync your Google Calender with Thunderbird Lightning.



Actual results:

Sometimes no notifications are shown in Thunderbird. 
Sometimes arlams are not shown in the main arlams window where you can snooze or dismiss an arlam. 

Popup of Window without reason. Sometimes repeating of an arlam is shown. 
Dismiss all not dismiss all arlams.... repeating of arlam are possible. 


Expected results:

repair the miss-functional remember function.

Comment 1

[[:MakeMyDay]]

Are you using Google provider or CalDAV to access the Google calendar? If the former, are you on the latest version 1.0.3?

Please enable calendar.debug.log and calendar.debug.log in the config editor. Do you see anythoing in the console (ctrl+shift+j) when expiriencing the issue?

Comment 2

[thE_iNviNciblE]

Yes i'm useing the CalDAV.
Where can i see the latest version? i think it's the newest version.

i've enabled the both options also calendar.debug.log.verbose.

i'll report the issue.
it's annoying that dismiss is not working.
Sometimes i get a error message that the calender could not be updated (Google Server) its rarely.

Comment 3

[thE_iNviNciblE]

(In reply to MakeMyDay from comment #1)
> Are you using Google provider or CalDAV to access the Google calendar? If
> the former, are you on the latest version 1.0.3?
> 
> Please enable calendar.debug.log and calendar.debug.log in the config
> editor. Do you see anythoing in the console (ctrl+shift+j) when expiriencing
> the issue?

i've this message 3x "CalDAV: OAuth token expired or empty, refreshing"
and 2x but it should be 3x one dissmissed event popup again...
"CalDAV: Item modified successfully on JBM"
"aChangeLogListener=undefined
calendarURI=https://apidata.googleusercontent.com/caldav/v2/dummesaol%40gmail.com/events/ 
iscached=false
this.mQueuedQueries.length=0"

i hope this helps you to fix the bug.

Comment 4

[[:MakeMyDay]]

Can you please confirm, whether this is still an issue with current beta 4.0?

Comment 5

[[:MakeMyDay]]

Confirming with current Lightning 4.5 for Daily. See also bug 1185375. The shorter the refresh interval of a calendar is, the more severe the issue gets from user perspective.

Once a networks calendar gets refreshed, the reminder popup gets closed irrespective of any existing alarm widgets. After the default snooze length is elapsed, the popup shows up again until the next calendar refresh.

Comment 6

[Philipp Kewisch [:Fallen] [:📆][:🧩]]

I wonder how we regressed this. It would be nice to fix this soon.

Comment 7

[Matthew Mecca [:mmecca]]

I can reproduce this with a large local ics calendar also, it sounds the same as Bug 1183031. I think it's caused by a timing issue with slower refreshes. When the calendar refresh starts, all of the reminders for that calendar are supposed to be removed from the dialog, then added back in asynchronously one by one. There's a 500 ms delay [1] to prevent the dialog from closing while it's empty, but in this case that elapses before any of the reminders are added back in, and the window is closed. However, by the time the onunload event is fired, some reminders have been added back into the dialog, and the dialog snoozes them for the default snooze length, as would happen if the dialog were manually closed.

We could increase the timeout, but I'm not sure that's the best solution.

[1] http://mxr.mozilla.org/comm-central/source/calendar/base/content/dialogs/calendar-alarm-dialog.js#291

Comment 8

[Matthew Mecca [:mmecca]]

Attachment: Fix v1

This patch prevents the alarm dialog from closing while the alarms are still being loaded, without relying on a timeout.

Comment 9

[Philipp Kewisch [:Fallen] [:📆][:🧩]]

Comment on attachment 8651579 [details] [diff] [review]
Fix v1

Review of attachment 8651579 [details] [diff] [review]:
-----------------------------------------------------------------

Can you add update the unit test for this patch? With a passing unit test, r=philipp.

Comment 10

[thE_iNviNciblE]

Now everthing is working correctly.

nice work! :-)

Comment 11

[Matthew Mecca [:mmecca]]

Attachment: Fix v2

While adding the test coverage for these changes I found that only about 25% of the tests in test_alarmservice.js were actually running - the multiple callbacks in the initialization code before the first run_next_test call seems to break the async test list causing it to exit early. With these changes the test should be fully running and passing again.

Comment 12

[Philipp Kewisch [:Fallen] [:📆][:🧩]]

Comment on attachment 8663352 [details] [diff] [review]
Fix v2

Review of attachment 8663352 [details] [diff] [review]:
-----------------------------------------------------------------

Thanks for catching this problem! r=philipp

Comment 13

[Matthew Mecca [:mmecca]]

Attachment: Patch for checkin

Comment 14

[Sebastian Hengst [:aryx] (needinfo me if it's about an intermittent or backout)]

https://hg.mozilla.org/comm-central/rev/243713ca559c

Comment 16

[Todd]

I'm not sure what the solution is but you've closed my bug as a duplicate.  What am I supposed to do to make it work?

Comment 17

[[:MakeMyDay]]

Todd, this fix will be part of Lightning for the next TB stable release. This cannot be backported to TB38. If you don't want to wait, you can switch to Aurora or Beta builds of TB 44 (currently Aurora) with the according Lightning version 4.6.

Comment 18

[Todd]

(In reply to MakeMyDay from comment #17)
> Todd, this fix will be part of Lightning for the next TB stable release.
> This cannot be backported to TB38. If you don't want to wait, you can switch
> to Aurora or Beta builds of TB 44 (currently Aurora) with the according
> Lightning version 4.6.

How much longer till this gets resolved?  This is ridiculous to have to wait over a year to have a very important piece of functionality restored.  This should've been a top priority fix because important items go missed as a result.  Conceivable someone might forget an interview or fail to complete a contract on time and it could cost them dearly.  This must be resolved.

Comment 19

[Todd]

And it shouldn't be listed as resolved because it's not.  Programmatically it might be fixed but no one has the fix.

Comment 20

[Philipp Kewisch [:Fallen] [:📆][:🧩]]

It is resolved, but it is not available in the latest release version. As mentioned you can use beta releases if you need this now, you can visit the AMO page of Lightning and go to the "Developer Channel" box. Major releases are only done every 42 weeks. This is how the Mozilla bugtracker works, it is resolved once it has been deployed in the latest nightly builds.

Comment 21

[Todd]

A beta release implies there could even be more problems.  As a user of this software it needs to be at a service level that insures that the main features function.  I don't mean to be coming down on you personally but you've got to understand that as a user that depends on your software you've made it impossible for me to continue to trust that it will function.

This kind of performance is only going to insure that this product won't continue in the long run because people like me will abandon it for something more trustworthy.  I have been a Thunderbird user for years and have supported this type of user-supported software creation as much as I am able.

As a software company or whatever you call yourselves you need to identify what your core functions are that must operate at all times without question even if it means an entire team must stay up and work all night long. 

If I count them you have sending mail, receiving mail, writing mail, creating appointments, maintaining appointments, appointment notifications, addressing mail and retention of both mail and appointments. In my mind those are the 9 functions that make up your product that are invaluable.  You might argue that email and appointments are the backbone of communications between everyone and that there really aren't any functions that exist in this software that are expendable.  In other words this software is mission critical.

This failure may have already cost me dearly because I missed an important deadline.  I can't take the chance that it may happen again.  You're one of the few industries that fails to have any accountability to your consumers. I think that's wrong but the US Government gave the industry an out and that's part of the problem of why software tends to fail.  I guarantee if you had to face legal suits like other industries...well you get the point.

I hope you share this with whoever oversees this project.

Comment 22

[Philipp Kewisch [:Fallen] [:📆][:🧩]]

I understand that you would like to see this issue in the release right now, but as I understand it this is an edge case. Reminders are generally shown, but there can be a case where the window is closed. It pops up again after the default snooze length, which is 5 minutes by default. If more issues pile up, I can consider this for the next 4.0.x release, but given the next major release is around the corner I don't think it is worth it. This issue must have been around for ages, since the code in that area has not significantly changed. 

We are not a software company, we are a community project and while we carry the Mozilla name, the work we do is volunteer time only. There is no pressure to stay up all night, because no one is paying us to fix issues. This is often how open source projects work. This bug is not the place for ranting though, please accept that it takes a while between a bugfix and it being in the release. I'll keep this in mind when starting the next point release though and consider it for inclusion.

Thank you for your understanding.

Comment 23

[[:MakeMyDay]]

Philipp, regarding 4.0.x backport, please keep in mind this patch contains an interface change.

Comment 24

[Kent James (:rkent)]

I don't see any reason why we could not accept an interface backport in js-only code that simply adds a new attribute to an interface.

Comment 25

[Todd]

This is not my bug.  My bug was closed as a duplicate.  Mine was bug 1228898.  I wrote that problem up back on November 29th of 2015.  When I looked back at it my only complaint at that time was that I couldn't get to the pop-up box it was hidden behind the main program.  I had no complaint about items appearing at wrong times.  I'm not even sure what fixed my initial problem (perhaps some addon update had messed me up that I have gotten rid of or got corrected) but now I'm left with the problem of outdated pop-ups.  Mine are NOT delayed by 5 minutes but sometimes won't show up till 3 or 4 days later if at all.  From what you've described above it doesn't even sound like the same problem.  And maybe since you only see this as a 5 minute problem you're not seeing it with the same seriousness that I am.

Comment 26

[Matthew Mecca [:mmecca]]

(In reply to Todd from comment #25)
> This is not my bug.  My bug was closed as a duplicate.  Mine was bug
> 1228898.  I wrote that problem up back on November 29th of 2015.  When I
> looked back at it my only complaint at that time was that I couldn't get to
> the pop-up box it was hidden behind the main program.  I had no complaint
> about items appearing at wrong times.  I'm not even sure what fixed my
> initial problem (perhaps some addon update had messed me up that I have
> gotten rid of or got corrected) but now I'm left with the problem of
> outdated pop-ups.  Mine are NOT delayed by 5 minutes but sometimes won't
> show up till 3 or 4 days later if at all.  From what you've described above
> it doesn't even sound like the same problem.  And maybe since you only see
> this as a 5 minute problem you're not seeing it with the same seriousness
> that I am.

The second line of the description in your original report in Bug 1228898, "Then there's usually a flash of the event box but now it has nothing in it and it closes.", sounds like the issue in this bug, but the "3 or 4 days later if at all" part does not. Even if the issues are not the same, they may be related and could have a common cause that is fixed in this bug. I'll reopen your original bug report and un-mark it as a duplicate until it's determined that this fixes it.