327992 - alarm dialog should use the DESCRIPTION property

Status: NEW

(Calendar :: Alarms, defect)

Description

[Joey Minta]

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.

Comment 1

[Reed Loden [:reed]]

The bugspam monkeys have struck again. They are currently chewing on default assignees for Calendar. Be afraid for your sanity!

Comment 2

[Matthew (lilmatt) Willis]

(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". 
iCal.app 2.0.3 (1058) serializes the following VALARM:

BEGIN:VALARM
ACTION:AUDIO
TRIGGER:-PT15M
X-WR-ALARMUID:90DDB76F-FD81-41EA-B8A5-D3E78A1264CA
ATTACH;VALUE=URI:Basso
END: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.

Comment 3

[Simon Paquet [:sipaq]]

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

Comment 4

[Simon Paquet [:sipaq]]

Attachment: Add description field to alarm widget

Comment 5

[Stefan Sitter [:ssitter]]

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

[Simon Paquet [:sipaq]]

Attachment: Screenshot for UI review

Comment 7

[Matthew (lilmatt) Willis]

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.

Comment 8

[Simon Paquet [:sipaq]]

Reassigning to nobody since a patch in the desired form is beyond my skills.

Comment 9

[Matthew (lilmatt) Willis]

Not going to make the 0.5 train.

Comment 10

[Andrew McMillan]

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.

Thanks,
Andrew McMillan

Comment 11

[Andrew McMillan]

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

[Michael Staats]

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

[bugzilla]

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

[Jochen F.]

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

[Jochen F.]

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");
            comp.addProperty(descriptionProp);
        } 

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

[Andrew McMillan]

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.

Comment 17

[Philipp Kewisch [:Fallen] [:📆][:🧩]]

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

Comment 18

[RH]

This is still an issue (Thunderbird 60.9.0): VALARMs are generated with (localized) "DESCRIPTION:Default Mozilla Description".

I suggest using the event's summary instead.