Closed Bug 529813 Opened 10 years ago Closed 10 years ago

Invite Attendees dialog: icons are messed up in case of missing participation role


(Calendar :: Dialogs, defect)

Not set


(Not tracked)



(Reporter: ssitter, Assigned: nomisvai)




(4 files, 2 obsolete files)

Attached file sample ics file β€”
Lightning 1.0pre (20091118) with Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv: Gecko/20091119 Shredder/3.0.1pre

In case of an attendee without participation role the icons in the Invite Attendees dialog are messed up. This issue has been reported in the German forum <>.

Steps to reproduce:
1. Import the attached sample ics file
2. Edit the event and open the Invite Attendees dialog
3. Check list of attendees on the left

Actual result:
Icons are messed up for the fourth attendee, see attached screenshot.

Expected result:
Do not break display on missing participation role.
Attachment #413320 - Attachment mime type: application/octet-stream → text/plain
Attached image screenshot β€”
Flags: blocking-calendar1.0?
Currently we always set the role icon regardless if role is set or if role is undefined. <>

RFC 5545 states the following for Participation Role:

  > If not specified on a property that allows this parameter, the
  > default value is REQ-PARTICIPANT. Applications MUST treat x-name and
  > iana-token values they don't recognize the same way as they would the

So the correct behavior would be to display the REQ-PARTICIPANT icon.
Hence, the right behavior should be to show the "REQ-PARTICIPANT" icon in the dialog when the event (that comes from another calendar application) doesn't have the role or has a bad role not included in specifications.

But should Lightning change the bad role stored in the calendar to the default one ("REQ-PARTICIPANT") only when the user opens the attendee dialog or should it change just after the invitation has been accepted?
Or should this be only a problem that concerns the icon showed in the dialog but not the role value stored in the calendar (Lightning shows the REQ-PARTICIPANT icon but stores the original role value, even if wrong)?
Duplicate of this bug: 538955
Duplicate of this bug: 536276
Assignee: nobody →
Attachment #431125 - Flags: review?(philipp)
OS: Windows 7 → All
Hardware: x86 → All
Attached patch Fallback using CSS instead (obsolete) β€” β€” Splinter Review
I'd prefer we fix this on the CSS side to allow potential userChrome.css to differ between a not specified role and the REQ-PARTICIPANT role.

Please test this in a real environment, I only did a basic smoketest. Feel free to adapt if I did something wrong.
Attachment #431125 - Attachment is obsolete: true
Attachment #431421 - Flags: review?(
Attachment #431125 - Flags: review?(philipp)
Attachment #431655 - Flags: review?(philipp)
Comment on attachment 431655 [details] [diff] [review]
[checked in] Fixed role attribute not set properly and add loading of the needed calendar-ui-utils script

Attachment #431655 - Flags: review?(philipp) → review+
Pushed to comm-central <>

Closed: 10 years ago
Flags: blocking-calendar1.0?
Resolution: --- → FIXED
Target Milestone: --- → 1.0b2
Does the patch need the pinstripe part for the file calendar-event-dialog.css?

I've tried the latest nightly, and I've seen that the icon related to the last attendee (see ics calendar attached) doesn't change when clicking on it, even changing the attendee with a new one that has a  "Needs action" status (but again without a role) e.g.


Is it the right behavior?
Duh, of course it needs a pinstripe change :-( I really need to get bug 533096 fixed soon, this has happened to me more than once lately! I'll also fix the other bug while I'm at it, thanks for noticing!
Resolution: FIXED → ---
Attachment #431655 - Attachment description: Fixed role attribute not set properly and add loading of the needed calendar-ui-utils script → [checked in] Fixed role attribute not set properly and add loading of the needed calendar-ui-utils script
Attachment #432906 - Flags: review? → review?(
Duplicate of this bug: 539653
Attachment #432906 - Flags: review?( → review+
Pushed to comm-central <>

Closed: 10 years ago10 years ago
Resolution: --- → FIXED
Duplicate of this bug: 554038
Duplicate of this bug: 570456
You need to log in before you can comment on or make changes to this bug.