alarm dialog should use the DESCRIPTION property



13 years ago
4 years ago


(Reporter: Joey Minta, Unassigned)




(1 attachment, 1 obsolete attachment)



13 years ago
Proper VALARMs are serialized with a DESCRIPTION property that ought to correspond to the text that is displayed to the user.  As of bug 315051, we at least create a description property, but there is never any visual display of that information.
The bugspam monkeys have struck again. They are currently chewing on default assignees for Calendar. Be afraid for your sanity!
Assignee: base → nobody
(In reply to comment #0)
> Proper VALARMs are serialized with a DESCRIPTION property that ought to
> correspond to the text that is displayed to the user.
Keep in mind not all apps do this "properly". 2.0.3 (1058) serializes the following VALARM:


> As of bug 315051, we at least create a description property, but there is
> never any visual display of that information.
When we do, we should strip the "Mozilla Alarm:" part. It's not l10n-friendly as it stands now.


12 years ago
Assignee: nobody → bugzilla
Component: Internal Components → Alarms

Comment 3

12 years ago
*** Bug 313616 has been marked as a duplicate of this bug. ***


12 years ago
Severity: normal → minor
Target Milestone: --- → Sunbird 0.5


12 years ago
QA Contact: base → alarms

Comment 4

12 years ago
Created attachment 248837 [details] [diff] [review]
Add description field to alarm widget
Attachment #248837 - Flags: second-review?
Attachment #248837 - Flags: first-review?(lilmatt)


12 years ago
Attachment #248837 - Flags: second-review? → second-review?(mvl)
This bug is about the DESCRIPTION property of the VALARM component.

The duplicated bug and the patch are about the DESCRIPTION property of the VEVENT/VTODO component.

The latter doesn't seem useful to me. Especially if the event description is rather long you have to scroll hundreds of pixels to the right to reach the Snooze button and read the text because it's shown in one line.

Comment 6

12 years ago
Created attachment 248842 [details]
Screenshot for UI review


12 years ago
Attachment #248837 - Flags: ui-review?(mvl)
Comment on attachment 248837 [details] [diff] [review]
Add description field to alarm widget

ssitter's right.

This bug is about the DESCRIPTION associated with the VALARM being shown to the user.

We could show it, and fall back to the VEVENT/VTODO's DESCRIPTION (perhaps truncated to a reasonable length to avoid the super-wide dialog issue mentioned previously).  Since we set it to "Mozilla Alarm" now, we'd want to fall back if the VALARM's description is empty or only "Mozilla Alarm".

Minusing on the fact that this patch doesn't fix the problem described in the actual bug.

mvl/dmose: Do either of you have any strong feelings as to what (if anything) we should show to the user, and if we should care about the VALARM's DESCRIPTION?  I'm currently unaware of any apps that do anything interesting with it, but that doesn't mean much.
Attachment #248837 - Flags: second-review?(mvl)
Attachment #248837 - Flags: first-review?(lilmatt)
Attachment #248837 - Flags: first-review-


12 years ago
Attachment #248837 - Attachment is obsolete: true
Attachment #248837 - Flags: ui-review?(mvl)

Comment 8

12 years ago
Reassigning to nobody since a patch in the desired form is beyond my skills.
Assignee: bugzilla → nobody
Not going to make the 0.5 train.
Target Milestone: Sunbird 0.5 → ---
Depends on: 353492

Comment 10

7 years ago
I'm the author of aCal, a CalDAV client for Android which regularly has to deal with events created by other software such as Lightning.

aCal displays the value of the DESCRIPTION property on a VALARM to the end user when an alarm is triggered.  If this is not present then it falls back to displaying the value of the SUMMARY from the containing VEVENT/VTODO.

That seems like reasonable behaviour to me.

So when aCal sees an event created by Lightning it displays the text "Default Mozilla Description".  Even *Lightning* ignores the very value it writes!

Can we please:

 (a) Not populate the VALARM with a silly meaningless default value
 (b) offer the user the opportunity to enter an actual description into the VALARM

I'm sure a fix for (a) must be something of a trivial change.

Andrew McMillan

Comment 11

7 years ago
On IRC Phillip points out that DESCRIPTION is mandatory for display (and e-mail) components per RFC5545.  So I'll bring this up at CalConnect in a couple of weeks also, and try to get that mandatoriness removed for the next revision of the iCalendar specification.

Meanwhile, if Mozilla is to insist on writing a DESCRIPTION property, which I guess is reasonable if the spec says it's non-optional, it should still default to something like the enclosing event/task SUMMARY...

Comment 12

7 years ago
This is probably related:

Lightning does not display any alarm at all if the DESCRIPTION is not "Mozilla Default Description". I. e. the alarm symbol is shown in the GUI, but the alarm is never displayed.

See also my report 687733.

Comment 13

7 years ago
As an avid user of aCal, I completely agree that if a value MUST be present, it should be something meaningful! 
Two ways :
1/ Give the user the "option" to enter his Alarm description AND if he doesn't fill out the field, use the X first characters of the "Title" OR "Description" field.
2/ No choice, just use the X first characters of the "Title" OR "Description" field.

imho, I think the second is the quickest to implement and the most efficient. Normally, the title of an event should be clear and concise enough to be suitable for an "alarm description".

I hope this can be solved quickly. As a non programmer, I'm willing to test.

Comment 14

7 years ago
As a user of aCal I can second this. Please use a meaningful description in VALARM. A quick and good solution would be to assign the VEVENT/VTODO SUMMARY field to VALARM:DESCRIPTION until is editable by the user.

Comment 15

7 years ago
Here is a quick workaround for non-english aCal useres (aCal has it's own workaround matching the english default text):

Edit file calAlarm.js and search for the following lines:

        // Set up the description (REQUIRED for DISPLAY and EMAIL)
        if (this.description ||
            this.action == "DISPLAY" ||
            this.action == "EMAIL") {
            let descriptionProp = icssvc.createIcalProperty("DESCRIPTION");
            // description needs to have a non-empty value
            descriptionProp.value = this.description ||
                calGetString("calendar", "alarmDefaultDescription");

and comment out the line

//       this.action == "DISPLAY" ||

This way no description tag ist generated and aCal uses the summary from the event.

Comment 16

7 years ago
I discussed this with other calendaring developers at the last CalConnect and the consensus was that the best solution which stays within the specification is to have an empty DESCRIPTION field, rather than populating it with a bogus value.

I added a hack to aCal to detect the silly default that Mozilla puts in there and ignore it, and just last week I started getting complaints from German users about this problem, because the default is being translated, making recognition and replacement considerably more annoying.
With the new javascript libical, I can make it so that its possible to add empty properties. Setting dependencies to make sure we don't forget
Depends on: 677982
You need to log in before you can comment on or make changes to this bug.