Keep the calendar notification open to require user interaction
Categories
(Calendar :: Alarms, enhancement)
Tracking
(Not tracked)
People
(Reporter: saschanaz, Unassigned)
References
Details
Calendar notification is important enough to require user interaction, as it frequently needs a real time response. Gecko supports requireInteraction parameter for both DOM notification and nsIAlertsService, so it should be straightforward to set the parameter where it's needed.
|
Reporter | |
Updated•2 years ago
|
|
|
Reporter | |
Comment 1•2 years ago
|
||
Looks like CalAlarmMonitor can pass aRequireInteraction as defined in nsIAlertsService.
|
|
Reporter | |
Comment 2•2 years ago
|
||
Hey Calendar module owners, can you confirm this is the direction you would want? Thanks!
|
||
Comment 3•2 years ago
|
||
I can see how that might be useful, although I think the user should be allowed to choose which notifications it's enabled for. That would be a slight problem as all we store is a list of times when we show a notification, there's no capacity for other options.
I did a little experimentation and changing the parameter made no difference on my machine (Linux Mint) – all of my notifications require dismissing but they quickly disappear to a task bar icon.
|
|
||
Comment 4•2 years ago
|
||
The other potential problem is that clicking on a notification opens a window for the event details, when the user probably just wants the notification to go away.
|
|
Reporter | |
Comment 5•2 years ago
|
||
(In reply to Geoff Lankow (:darktrojan) from comment #3)
That would be a slight problem as all we store is a list of times when we show a notification, there's no capacity for other options.
There should at least be time AND a corresponding notification info to be shown, right? Can this be included in the notification info?
I did a little experimentation and changing the parameter made no difference on my machine (Linux Mint) – all of my notifications require dismissing but they quickly disappear to a task bar icon.
Looks like that's bug 1417846. 👀
The other potential problem is that clicking on a notification opens a window for the event details, when the user probably just wants the notification to go away.
Not sure about that, clicking a notification is an action of "show me details", isn't it? Not sure why one would want it to just go away. Or is it not the case on Linux?
|
|
||
Comment 6•2 years ago
|
||
That would be a slight problem as all we store is a list of times when we show a notification, there's no capacity for other options.
There should at least be time AND a corresponding notification info to be shown, right? Can this be included in the notification info?
What I'm saying is that Thunderbird remembers the notifications settings as a preference, and it's just a comma separated list of times (relative to the event time). (calendar.notifications.times for all calendars and calendar.registry.xxxx.notifications.times per-calendar.) We'd have to change how the data is structured. Not impossible, but a small problem.
The other potential problem is that clicking on a notification opens a window for the event details, when the user probably just wants the notification to go away.
Not sure about that, clicking a notification is an action of "show me details", isn't it? Not sure why one would want it to just go away. Or is it not the case on Linux?
I see notifications as a reminder that I need to do something, and the notification itself is usually enough of a reminder. I probably don't want to interact with the program at that point. I suppose I could dismiss it by clicking on the X, but it's a much smaller target.
Anyway, how I'd use it is probably irrelevant as I don't usually use calendar notifications. I think I'd be willing to accept a patch for this as long as requiring interaction was optional.
Description
•