Open Bug 360916 Opened 18 years ago Updated 2 years ago

Snoozed alarm fires at old event time although event time has been changed

Categories

(Calendar :: Alarms, defect)

defect

Tracking

(Not tracked)

ASSIGNED

People

(Reporter: kelv, Assigned: Fallen)

References

Details

(Whiteboard: [patchlove][needed beta][no l10n impact])

Attachments

(1 file, 2 obsolete files)

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1) Gecko/20061010 Firefox/2.0
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1) Gecko/20061010 Firefox/2.0

I have an event starting at 8.15am. The event is rescheduled to 10.15am so I change the event time. The event moves successfully to 10.15am. However its alarm notice pops up X minutes before 8.15am still.

Reproducible: Always

Steps to Reproduce:
1.Create an event and give it an alarm say 15 minutes before.
2.Let the first alarm event go off. Snooze it.
3.Change the event time to a later time same day.


Actual Results:  
The alarm reminder will appear for the original event time.

Expected Results:  
The alarm should not go off until X minutes/hours before the new event time.
This works for me with Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9a2pre) Gecko/20070103 Calendar/0.4a1 ID:2007010305

Kelv, are you still having this Problem?
1) 
The first issue mentioned by the reporter is rescheduling the event before the alarm was fired --> this works for me using Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1.3pre) Gecko/20070314 Calendar/0.5pre ID:2007031404

2)
The second issue mentioned in the STR a different one. The alarm was already fired and was snoozed for x minutes. Afterwards the event was rescheduled.
--> Snooze just means 'Remind me again in x minutes'. From reading the reporters results the application worked that way. I see no error here since the application works as expected in my opinion.
I agree with ssitter, this most likely is the intended behaviour. But better would be to have the alarms re-set after the event-time has changed. What happens after the second alarm has fired, does the third one get recalculated on basis of the new eventtime, so does it fire at:
new-time -/- alarmtime  + snoozetime1 + snoozetime2
or (as it should imho) at
new-time -/- alarmtime
(so the alarm got reset)
I reproduced the issue here with Sunbird: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8.1.4pre) Gecko/20070427 Calendar/0.5pre

When the snoozed alarm fires, it states the new time of the event.  For example, if the event was at 10:30am, you snooze the first alarm for 5 minutes and reschedule the event for 12:30PM on the same day.  In five minutes, your snoozed alarm refires, and the event is listed as occurring at 12:30PM.  You have the option to either snooze the alarm again (and give it a certain amount of time before the alarm pops up) or to dismiss the alarm now.

I think that the user can simply choose to re-snooze the alarm for an hour, and see the alarm pop up again before the event.  

I agree that snooze only means "remind me in x minutes/hours/etc". I don't want to get into the murky waters of trying to reset the alarms and guess the user's intention after the event was rescheduled.  

Also, in my testing, I see that the event still fires its original alarm 15 minutes before the event.  So, I don't see the need to change any behavior.

I think this should be moved to -->INVALID since the desired result is in fact the way the code works. (This is not a bug).


If the alarm is to do with that event, I'm not sure it's expected that the user is re-purposing the alarm to do something else.  I'm not sure what is standard, but IMO if an alarm is tied to an event, it should stay tied to that event.

I think it's more likely that users are worried if they dismiss the alarm for the day that it won't go off at the new time, and so they snooze it rather than dismiss and then reschedule the event.

ctalbert - the alarm fires again before the rescheduled event even if the snoozed alarm is dismissed?  If so, IMO the snoozed alarm should be detached from the event if it's still going to exist, otherwise dismissing it should also dismiss the alarm for the new time.
Perhaps I wasn't specific enough. I have an event for which I have set an alarm. The alarm goes off and I snooze it for 5 minutes. Meanwhile in the time between the next alarm reminder someone mentions the event is going to be tomorrow instead. Therefore I drag the event to the next day. However the alarm notice I just snoozed for the now rescheduled event pops up again 5 minutes later.

Can't it be assumed therefore that if I moved the event there's no point in the snoozed alarm going off again, and that it should next remind me X minutes before what is now tomorrows event?
I agree with Kelv.

I set an event with an alarm.  I did not realize that I had set it for the wrong date.  When the alarm went off, I moved the event to the correct date, but there was no way to get the alarm to snooze to the proper time.

I eventually had to remove the alarm from the event, and then add it back.

A better behavior would be to have snoozed alarms cancelled when an event is moved, and reinstate the alarm to the new time as configured with the event.(In reply to comment #6)
> Perhaps I wasn't specific enough. I have an event for which I have set an
> alarm. The alarm goes off and I snooze it for 5 minutes. Meanwhile in the time
> between the next alarm reminder someone mentions the event is going to be
> tomorrow instead. Therefore I drag the event to the next day. However the alarm
> notice I just snoozed for the now rescheduled event pops up again 5 minutes
> later.
> 
> Can't it be assumed therefore that if I moved the event there's no point in the
> snoozed alarm going off again, and that it should next remind me X minutes
> before what is now tomorrows event?
> 

OS: Linux → All
Hardware: PC → All
I use Thunderbird 2.0.0.4 and Lightning 0.5

In my opinion, alarm should be linked to events/task.

In case events date or task due date is changed alarm should be changed also.

For example, my boss plan a meetic on 8° august 2007.
I have to prepare the powerpoint presentation. 
So I add a task with an alarm 3 days in advance.
Meeting is reschedule on 15th august 2007.
So I move in Lighning the task.

Personaly, I expect alarm to be re-schedule on 12th and not to keep initial alarm on 5th. I don't see the point to be alarmed 1 week in advance.

Alarm should be linked to task or event not to initial planning.

BTW what happen if meetic is rescheduled not on 15 but on 11th?
I will get the alarm 1 day after.
I will suck my presentation.
TOO BAD ;)




No, I don't believe that's how it works.

If you move the event the alarm *does* move.  What happens here is this:

1. You have an event scheduled with an alarm.  For the sake of these steps we'll say it's scheduled to go off 2 hours before the event.
2. Event is rescheduled but you haven't changed it in the calendar yet.
3. Alarm goes off, and you hit "snooze" or "remind me again in x amount of time." For the sake of these steps, we'll say 1 hour.
4. Reschedule the event to the correct time.

Results:

There will be two alarms now.  One will go off when it was told to snooze, in this case one hour, until you dismiss it.  The other will go off based on the rescheduled date, in this case two hours before the new time.

Someone please correct anything I got wrong!
Re: majken, you've got it wrong, sorry :/

What I'm saying is, and I'll use your example...

1. You have an event scheduled with an alarm set to go off 2 hours before.
2. Alarm goes off. You're snooze for 10 minutes as you're busy.
3. While snoozed, you learn event has been rescheduled to tomorrow.
4. You move event to tomorrow in Lightning/Sunbird.

The bug is that even though the event is now scheduled for tomorrow, the snoozed alarm for today comes back up 10 minutes later. Why? It's pointless if the event has moved to tomorrow. It should just dismiss itself when you moved the event.

I can't make it any clearer than that! :)
Kelv -  that's exactly what I said with the exception that you didn't mention whether or not the second alarm happens as well at the correct time.
Majken - no, in your point 2 you said the event isn't changed in the calendar yet. I'm saying it is, after the alarm for it has been snoozed as per the original bug posting and again in comment #6 :)
Kelv - the mechanics are the same. Alarm goes off, alarm is snoozed, event is changed.  Read my 3 and 4.
With respect to the calendar people that have already commented, ccing Christian for his UI expertise.

If the point of snooze is to simply remind about something in x time and not be attached to an event, then the alarm UI shouldn't mention the event it's reminding you about.  Otherwise IMO it doesn't make sense to observe the snooze after the event is edited. (already made this point of course, restating to summarize what I would like the opinion on).
Kelv and I were discussing this on IRC further...
[1:48pm] chiller2: ctalbert, what do you think about bug 360916, especially my last comments?
[1:48pm] ctalbert: I understand that it does seem silly to be reminding you about an event that has been moved to tomorrow.
[1:48pm] ctalbert: But, when we set the Snooze timer, it just goes off whenever we set it.
[1:48pm] ctalbert: It doesn't requery to see if the date changed.
[1:49pm] ctalbert: What majken is saying should also be correct, yes, you get the spurious snooze, but the original alarm should still go off x minutes before the new rescheduled time.
[1:50pm] ctalbert: However, I bet that the real kicker of this bug is this:

1. You get the extra alarm after modify the event by moving it to the next day
1a. That's the spurious snooze ^
2. You click DISMISS on that
3. Then on the next day, your alarm doesn't fire.

[1:51pm] ctalbert: That's a bug ^^^ I'd be much more interested in fixing.
[1:51pm] ctalbert: The extra snooze might be wrong, but I think that the amount of annoyance it causes is relatively low to the amount of code that would be changed to fix it.
[1:52pm] ctalbert: And, I think that if we fixed it, we'd open another can of worms where snooze suddenly had to try to watch for all types of modifications to the event in question, and that could get ugly fast.
[1:57pm] chiller2: yes, I see what you're saying now. I didn't realise majken was saying what he was.
[1:58pm] chiller2: I think that when the event moves, any alarm tied to it, snoozed or not, should move too, which it does, but then the snooze shouldn't come up, then you couldn't dismiss it by accident.
[1:58pm] chiller2: did that make sense?
[1:59pm] chiller2: or rather, going back to my point of why bring up the snoozed alarm again if the event has since moved to tomorrow. If my proposed behaviour comes into play, the user can't dismiss by accident, so we both win.
[2:01pm] chiller2: (as in they can't dismiss by accident until tomorrow when the alarm fires x mins/hrs before the new event time)
[2:03pm] ctalbert: that is true.  Not displaying the bad snooze is a way to prevent you from dismissing the real (and reshceduled) alarm

Kelv is going to try to put a wiki together to sort out all the expected issues around the alarm/snooze/event modfication action.  I think we need to take a hard look at alarms for the 0.9 release and ensure that we have all these issues as well as the others (empty alarm dialogs, timezones, our use of X-Properties etc.).
I have made a start on the above suggested wiki page. Please feel free to add your notes for other alarm behaviours. New designs and use cases can be created which will help give the discussion enough momentum to go the next level.

The URL is http://wiki.mozilla.org/User:Chiller2:CalendarAlarms 
Summary: Alarm using old event time even if event time is changed → Snoozed alarm fires at old event time although event time has been changed
I can confirm this issue also on Mozilla/5.0 (Windows; U; Windows NT 5.1; it; rv:1.8.1.17) Gecko/20080914 Lightning/0.9 Thunderbird/2.0.0.17 ID:2008091421
Confirming per duplicates.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Flags: wanted-calendar1.0?
Clearly, the alarm should ***AUTOMATICALLY*** be rescheduled if the event is itself rescheduled.

Those who suggest that the "snooze delay" should take precedence over a subsequent rescheduling of the event itself are, IMHO, taking too literal an interpretation of the snooze function.

Consider this scenario (use case):

~~~

(1) You are in a project review meeting and have to leave directly from the meeting to take a cab to the airport to catch a flight departing a 6pm, but need to be at the airport 1 hour before, and also need 25 minutes to get to the airport.  So, you you ask the meeting assistant to remind you to call a cab to arrive at the building 90 minutes before the flight to get you to the airport one hour before your flight.

(2) The meeting is now clearly taking longer than expected, so around 3:30pm, you ask the assistant to reschedule your flight an hour or two later.  

(3) The meeting assistant comes back and confirms that the flight has now been rescheduled at 7:45pm.  Therefore you need to leave the meeting no later than 6:15pm.

(4) The same meeting assistant then comes back at 4:30pm to tell you that your taxi is waiting to take you to the airport!!!

(5) All eyes at the meeting roll and the assistant lets out an "Oh!!!" and blushes profusely as they leave the meeting room.

~~~

NOW, does anyone NOT see a problem with this scenario (use case)?!?

It is illogical for the alarm to repeat after a fixed snooze period if the event has to which the alarm applies has meanwhile been rescheduled. 

Clearly, the alarm should be RELATIVE to the event.  In fact, ALL of the alarm settings choices are xx minutes/hours/days BEFORE the scheduled event.

This is a design and usability issue.

Sure, if you look at the snooze function in isolation of the primary mission (to assist users in time management), you could argue that the alarm should unilaterally repeat after the alloted period after the user hit the snooze button, but that would not be (is not) a terribly intelligent behavoir.

This is not how users would expect this to work.

From a design and usability perspective (not to mention time management effectiveness perspective), this can be resolved by cancelling any pending snoozed alarm events and re-initializing alarms when the primary event is rescheduled.

This would best be implemented by setting alarms to be always RELATIVE to the event itself.  At the same time, automatically cancel any snooze function if the alarm horizon (xx min/hr/day before) has not been reached.

As is now, if you "DISMISS" the alarm, you then find that if you open the event that the alarm is still (apparently) set.  Confusion sets in, since you know that you just dismissed the alarm, so it is difficult to know what the alarm status is.  So, to be sure, set to "NO REMINDER" then "SAVE" ... then (re)"OPEN" the event and (re)"set" the alarm as required.

To recapitulate, as things are now.  If the alarm rings after snoozing, even though the event has now been rescheduled, the user will likely have to take SEVEN steps to be somewhat confident that the alarm will now ring relative to the rescheduled event time:

(1) DISMISS alarm

(2) Open event

(3) Set alarm to "No reminder"

(4) Save

(5) Re-open event

(6) Re-set alarm to XX min/hrs/days before event

(7) Save

... perhaps not all these steps are necessary, but since the user does not see the code, they cannot be sure what will happen if they skip any of the above steps.

Needless to say, this is tedious and annoying to the user.

To anyone still not convinced, imagine that you have been hired as a time manager / project manager and management is relying on you to remind them (if necessary) keep them all on schedule.  Oh, and also imagine that your career prospects and salary reviews depended on management appreciating your timely reminders...

~~
Flags: wanted-calendar1.0? → blocking-calendar1.0+
Whiteboard: [not needed beta][no l10n impact]
I fully concur, the behaviour is entirely unnatural as a user of TB.  The problem is still extant in 3.1.4 and is a complete pain, if event(task) deadlines are updated daily on a re-prioritisation basis.  In fact, this feature of TB is pretty much useless to me and I have moved back to Lotus Organiser(!) because this works intuitively - and as well displays tasks-with-dates on the calendar (another very useful feature missing in TB).
That said, I do very much like TB for its mail features - an excellent product that I much prefer to any of the MS alternatives (or anything else that I have tried over the years).
Iain.
I experience something similar, except I was trying to dismiss the alarm, not use snooze. I imagine it doesn't make too much difference whether trying to snooze or dismiss.

Thunderbird 3.1.6, Lightning 1.0b2
Is the event-id stored in the alarm-table which is kept in memory with every session? If so, it shouldn't be too hard to loop through the snoozed alarms whenever an event is moved and delete those alarms from the memory-table.
Attached patch Fix - v1 (obsolete) — Splinter Review
Ok, this should solve the problem. I have an uneasy feeling adding more code to doTransaction, but on the other hand this needs to be done on every user-initiated transaction, no matter if from the views or the event dialog. Matthew, do you think this makes sense?
Assignee: nobody → philipp
Status: NEW → ASSIGNED
Attachment #549063 - Flags: review?(matthew.mecca)
Whiteboard: [not needed beta][no l10n impact] → [not needed beta][no l10n impact][needs review]
Attached patch Fix - v2 (obsolete) — Splinter Review
Oops, forgot to qref
Attachment #549063 - Attachment is obsolete: true
Attachment #549065 - Flags: review?(matthew.mecca)
Attachment #549063 - Flags: review?(matthew.mecca)
Attached patch Fix - v3Splinter Review
Ugh, sometimes the item is passed in immutable, so need to clone. As Ludovic has said, we need to rethink all this cloning and immutability thing...
Attachment #549065 - Attachment is obsolete: true
Attachment #549110 - Flags: review?(matthew.mecca)
Attachment #549065 - Flags: review?(matthew.mecca)
Comment on attachment 549110 [details] [diff] [review]
Fix - v3

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

Overall this makes sense, but has a few problems, r- based on those.

::: calendar/base/content/calendar-item-editing.js
@@ +418,5 @@
> + * @return          The changed item, for the transaction;
> + */
> +function dontSnoozeOnChange(aItem, aOldItem) {
> +    let changeItem = aItem;
> +    if (aItem[calGetStartDateProp(aItem)].compare(aOldItem[calGetStartDateProp(aOldItem)]) != 0 ||

This throws an error if the item is a task with no start date set.

@@ +424,5 @@
> +        // The dates have changed, make sure the snooze date has been removed on the new item
> +        if (aItem.parentItem != aItem) {
> +            if (aItem.hasProperty("X-MOZ-SNOOZE-TIME-" + aItem.recurrenceId.nativeTime)) {
> +                changeItem = aItem.clone();
> +                changeItem.deleteProperty("X-MOZ-SNOOZE-TIME-" + aItem.recurrenceid.nativeTime);

Should be recurrenceId (with capital I). In any case this doesn't really work, since the X-MOZ-SNOOZE-TIME-[recurrenceId] property needs to be removed from the parent item.

Another case this won't cover is modification of the whole series of repeating items after an occurrence is snoozed.
Attachment #549110 - Flags: review?(matthew.mecca) → review-
Whiteboard: [not needed beta][no l10n impact][needs review] → [not needed beta][no l10n impact]
Whiteboard: [not needed beta][no l10n impact] → [needed beta][no l10n impact]

Can the patch be finished off?

Flags: needinfo?(lasana)
Whiteboard: [needed beta][no l10n impact] → [patchlove][needed beta][no l10n impact]
Severity: normal → S3
Flags: needinfo?(lasana)
You need to log in before you can comment on or make changes to this bug.