Closed Bug 379392 Opened 19 years ago Closed 17 years ago

Cannot "dismiss" alarms from yesterday or earlier

Categories

(Calendar :: Alarms, defect)

defect
Not set
normal

Tracking

(Not tracked)

RESOLVED WORKSFORME

People

(Reporter: kevin.loebach, Unassigned)

Details

User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.3) Gecko/20070309 Firefox/2.0.0.3 Build Identifier: Mozilla Sunbird 0.3.1 The alarm seemed to be working fine for a while until one day it would no longer dismiss. Every time I clicked "dismiss" or "dismiss all" it would pop up again. I must have left Sunbird on for a while, and it kept displaying alarms and fell into a glitch. I'm not quite sure exactly. Reproducible: Always Steps to Reproduce: 1. 2. 3.
You say dismiss worked until one day, now it fails. What changed in between? Did you installed a new Sunbird version? A new extension? A new theme? A new calendar? What calendar do you use? Locale or Remote? What type? Do you try to dismiss alarms for events or tasks? Normal or repeating events/tasks? What happens if you press Dismiss? Is there an error message shown in the Error Console?
One day, I was using Sunbird as an alarm to wake up for school in the morning. I hit snooze and left to go to class and came back a couple of hours later, and it has been behaving the same ever since. I didn't install a new extension; I didn't add a new calendar; I haven't installed a new theme; I've kept the same Sunbird 0.3.1; I use standard local calendars; I try to dismiss a non-repeating event alarm; there weren't any messages in the Sunbird error console. Here is an image of the situation: http://web.umr.edu/~krlhc8/Images/sunbirdprtsc.jpg
Keywords: qawanted
Summary: alarm won't dismiss. only snooze works. → Alarm won't dismiss, only snooze works.
I am noticing this same behaviour since the upgrade to Lightning 0.5 on Windows XP with Tbird 2.0.0.4 but with more intensity. Neither the "snooze", "dismiss", nor "dismiss all" seem to work. The only way to close the alert window is to close the window itself (the red "X" in the top right corner), and then the alarms pop right back up again in a few minutes.
Sorry, I should add this: when you click on the buttons, you don't get any kind of error message. The input is just ignored as if you'd not done a thing.
I think this is likely related to Bug 356002
I think this is likely related to Bug 356002. I didn't mention that the alarms I'm having trouble with are remote alarms that are WebDAV'ed. I wonder if this is true of Kevin's report, as well.
I can confirm this. I never saw the problem with Sunbird 0.3 but after upgrading to Sunbird 0.5 a few days ago, _sometimes_ I have to click the close button to dismiss the alarm window. Furthermore, and this might be a different bug, the alarm window keeps popping up every 30 minutes or something like that. Most of the time, dismiss all closes it (but it keeps reappearing). First I thought it had something to do with the refresh web calender interval (that defaults to 30 minutes) but after changing that interval to 999 minutes (why can't I set it to update just once a day?) these alarms still pops up with the same interval. All calenders that show this problem are published from iCal/Mac OS X and read in Sunbird 0.5/WinXP
Kevin, does your issue still exists using a recent nightly build of Sunbird 0.7pre <http://ftp.mozilla.org/pub/mozilla.org/calendar/sunbird/nightly/latest-mozilla1.8/>?
I had to reinstall the software to stop the bug (this was months ago). So I can't confirm your question Stefan. Sorry!
I'm having the same issue in Thunderbird 2.0.0.6 and Lightning 0.7. No response to dismiss, dismiss all, or snooze. My calender is not read-only. As Kevin said it was working fine until "one day" to wasn't. The problem started before and persisted after the last upgrade (to TB 2.0.0.6).
I had the same problem with Sunbird 0.5, after upgrading to 0.7 the problem disappeared for a while, but the very same "one day" as above, it started in v. 0.7. It's a local calendar, and it's not read only. If I press Dismiss, the dialog just reappears instantly. If I press Dismiss All the dialog is hidden. If I close Sunbird and then reopen it, the alarm is shown again. I don't know, if this is related, but if I change the "Snooze for"-time and press Dismiss All, the "Snooze for"-time is set to the default value before the dialog is hidden. If I press Snooze everything is normal.
I experience the same pblem after upgrading to Vista and Lightning 0.7. To me it is NOT identical to bug 356002, since I have a read/write calendar (sync'ed whith Google Calendar). I can't get rid of the alarms from old appointments. If I press "Dismiss" I can see the button being pressed, but nothing else happens. If I press "Snooze" the item is snoozed. If I press Dismiss All, the alarm window disappear, but shows up next time I start Lightning. I'm running Windows Vista, Thunderbird 2.0.0.9, Lightning 0.7. All English (American) versions. Please ask, if you need any further information.
RasVed, does this also happen for non-google calendars? Please try with lightning 0.8pre and a gdata provider nightly from http://gdataprovider.mozdev.org/
If this happens for recurring events, maybe related to bug 397030
Similar problem here. I'm using Gcaldeamon to sync an ics calendar with google calendar, so i can also use the google calendar offline. A few old alarm keep popping up, everytime the ics file is synced. I can dismiss those alarms without any problem, but they reappear on every sync action.
lightning version 0.7, build 2007102304 eudora 8.0.0b1
splash: In your case this is probably an incompatibility of GCalDaemon and mozilla calendar. We use a non-standard property to save the snooze date. Gcaldaemon either needs to save all X-Props as a gd:extendedProperty, or needs to at least support our dismiss/snooze properties.
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.13pre) Gecko/20080319 Sunbird/0.8 Latest build: dismiss does not work any more. Have to close screen to get rid of alarm.
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.13pre) Gecko/20080323 Sunbird/0.8 Dismiss dont work, snooze dont work either, if the calendar is in read only. That's maybe a couse of some of these bugs? Sunbird tries to load calendars very soon (when PC is starting) and fails to do so and places them in read only.
(In reply to comment #13) > RasVed, does this also happen for non-google calendars? Please try with > lightning 0.8pre and a gdata provider nightly from > http://gdataprovider.mozdev.org/ Hi Philipp. I havn't tried with the gdata as suggested. I "updated" to Windows XP, and havn't experienced the problem ever since. -R
Ok, what about the other commenters? Does it work for you? Please recapitulate the most important information: Using what type of calendar? Tried with the latest calendar (and/or gdata) nightly? Any error console messages? (With calendar.debug.log enabled!) Using which operating system? Works with a fresh profile?
I have the same issue since this morning Lighting and Provider for Google calendar were updated: can't snooze, can't dismiss. This is only happening for 1 calendar entry which repeats weekly. It is a Google calendar entry. Just updated today. Just turned on by creating calendar.debug.log, but don't know where to look. XP Don't know.
Erik: you may be seeing bug 424185. There seem to be some google problems with recurring events on shared calendars (and even non-shared ones!). Please compare your error console with the messages in that bug.
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1b2pre) Gecko/20081013 Calendar/1.0pre This is not bug 424185 because (a) I have no shared calendars and (b) I'm seeing this after bug 424185 has been FIXED. What I'm seeing is this: - If I dismiss an alarm on the same day (before midnight), it works - If I've already departed to meet my appointment when its alarm is triggered, and come back after midnight, then it is not possible to "dismiss" the alarm anymore. The only workaround I've found is to edit the event (if repeating, edit only the current instance) to set it to "no reminder". This is IIUC the same symptom as in comment #12 above ("cannot get rid of old appointments"). I define "old" further as meaning "from yesterday or earlier". Also comment #3 (cannot "dismiss", and if the alarm popup is closed by it [X] button at top right, it will soon trigger again). I'm seeing this in the current trunk nightly (see UA string above) and I've seen it in the last 0.9 build too. (Reporter was on Sb 0.3.1.) Note: all my calendars (3 of them) are local *.ics files outside my profile. When I define a new event it is saved, and I see it again after closing and reopening Calendar (i.e., they are not opened read-only). Confirming and setting All/All (I'm on Linux, the reporter is on Windows).
Status: UNCONFIRMED → NEW
Ever confirmed: true
Keywords: qawanted
OS: Windows XP → All
Hardware: PC → All
Whiteboard: [trunk and 1.8 Branch]
Version: unspecified → Trunk
P.S. Editing Summary to describe the symptoms more precisely
Summary: Alarm won't dismiss, only snooze works. → Cannot "dismiss" alarms from yesterday or earlier
Whiteboard: [trunk and 1.8 Branch]
Lots of different symptoms, lots of different versions. I'd like to close this bug in favor of a new bug with explicit steps to reproduce (1. ..., 2. ..., 3. ...). If this problem persists for anyone, please file it. For issues with gdata and alarms, I believe there is a separate bug, I'll try to find that one soon.
Status: NEW → RESOLVED
Closed: 17 years ago
Resolution: --- → INCOMPLETE
In reply to comment #26: The symptoms I experienced when I confirmed the bug in comment #24 were as follows: 1. Define an alarm in Sunbird. 2. Wait (without touching it) until it triggers 3. Wait some more (don't dismiss it yet) until midnight comes and goes. 4. _Now_ try to dismiss the alarm. Expected results: You can. Actual results: You can't. As far as I'm concerned, this is now WFM with no precise date of "bug disappearance". Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1pre) Gecko/20090625 Calendar/1.0pre
Resolution: INCOMPLETE → WORKSFORME
You need to log in before you can comment on or make changes to this bug.