Open Bug 674337 Opened 14 years ago Updated 3 years ago

Refreshing CalDAV-only alarms in dialog window causes MANY, MANY replays of alarm sounds

Categories

(Calendar :: Alarms, defect)

Lightning 1.0b4
All
Linux
defect

Tracking

(Not tracked)

UNCONFIRMED

People

(Reporter: donrhummy, Unassigned)

Details

User Agent: Mozilla/5.0 (X11; Linux i686; rv:5.0) Gecko/20100101 Firefox/5.0 Build ID: 20110615151330 Steps to reproduce: (Assumes you have siz events with alarms all "due") 1. First time Alarm Dialog window pops up it plays 6 alarm sounds 2. You dismiss the first alarm, it refreshes the other 5, plays 5 alarm sounds 3. You snooze the next alarm, it refreshes the other 4, plays 4 alarm sounds 4. You snooze the next alarm, it refreshes the other 3, plays 3 alarm sounds 5. You snooze the next alarm, it refreshes the other 2, plays 2 alarm sounds 6. You snooze the next alarm, it refreshes the other 1, plays 1 alarm sounds ----------------------- TOTAL: plays 21 alarm sounds Actual results: It unnecessarily refreshed event alarms that were unrelated to the one you snoozed or dismissed and thus replayed all their alarm sounds. The refresh on every "decision" causes it to play an alarm sound for every event in the window. So if you have 6 events, and you deal with them one at a time, you'll have the alarm sound play 21 times! Expected results: It should have removed the item you snoozed/dismissed and left the others alone in the window.
Any progress on this?
Sorry for the delay. What kind of calendar are you using? Are you using the cached mode?
I'm using two calendars: gmail and ms exchange. How do I find out if it's cached mode?
How are these calendars connected to Lightning? Via the Provider for Google Calendar/MS Exchange, or via caldav? You can open the calendar properties (right click in calendar tab on the calendar list, properties), there should be a "Cache" checkmark.
caldav for exchange, provider for google. And no cache on either one.
Could you isolate if this happens on the caldav calendar or the provider by temporarily disabling one or the other? Also, just for the kicks, could you try enabling the cache for both? The refresh schedule should be much different then.
(In reply to Philipp Kewisch [:Fallen] from comment #6) > Could you isolate if this happens on the caldav calendar or the provider by > temporarily disabling one or the other? Wow, amazing! It only happens with the CalDAV one! With Google calendar, when I have multiple events in the alarm window and dismiss them one at a time, there's no replay of the alarm. But with multiple CalDAV events, every dismiss/snooze causes every other event's alarm sound to play again!
Ok, now two more things you can try out. First of all, enable the cache on the caldav calendar. Second, (this requires some more work): * Download and install Thunderbird 7 and Lightning 1.0b7 * Be sure to create a new profile, as the Lightning 1.0 profile won't work with an older version of Lightning (see http://support.mozilla.com/en-US/kb/Managing-profiles) * Subscribe to the caldav calendar again (without the cache) * Try to reproduce again
donrhummy, is this still an issue using the recently released Lightning 1.0 (compatible with Thunderbird 8)?
(In reply to Martin Schröder [:mschroeder] from comment #9) > donrhummy, is this still an issue using the recently released Lightning 1.0 > (compatible with Thunderbird 8)? Yes.
donrhummy, do you still see this issue? (PMed on 12/7 but no response)
Flags: needinfo?(donrhummy)
Whiteboard: [closeme 2016-01-15]
(In reply to Wayne Mery (:wsmwk, use Needinfo for questions) from comment #11) > donrhummy, do you still see this issue? > > (PMed on 12/7 but no response) I stopped using Thunderbird a few years ago. You'll have to ask someone who uses it now to test this.
Flags: needinfo?(donrhummy)
OS: Other → Linux
Summary: Refreshing alarms in dialog window causes MANY, MANY replays of alarm sounds → Refreshing CalDAV-only alarms in dialog window causes MANY, MANY replays of alarm sounds
Whiteboard: [closeme 2016-01-15]
Component: Lightning Only → Alarms
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.