Colliding events: events collide with special invitation status

VERIFIED FIXED in 0.9

Status

Calendar
Calendar Views
VERIFIED FIXED
10 years ago
10 years ago

People

(Reporter: Berend Cornelius, Assigned: Berend Cornelius)

Tracking

({regression})

unspecified
regression

Details

Attachments

(1 attachment, 1 obsolete attachment)

(Assignee)

Description

10 years ago
You can still observe overlapping events with open and unanswered invitations after "Bug 451353 – Emphasize open/unanswered invitations " has been integrated. As Andreas and me found out it is not particularly easy to reproduce but with many events this scenario occurs. Removing the css rules that were introduced by above mentioned bug 451353 improves the situation in this respect.
These rules seem to be causing this issue:
<+
<+calendar-event-box[invitation-status="NEEDS-ACTION"],
<+calendar-editable-item[invitation-status="NEEDS-ACTION"],
<+calendar-month-day-box-item[invitation-status="NEEDS-ACTION"] {
<+    border: 2px dotted black;
<+    opacity: 0.5;
<+}
<+
<+calendar-event-box[invitation-status="TENTATIVE"],
<+calendar-editable-item[invitation-status="TENTATIVE"],
<+calendar-month-day-box-item[invitation-status="TENTATIVE"] {
<+    opacity: 0.5;
<+}
<+
<+calendar-event-box[invitation-status="DECLINED"],
<+calendar-editable-item[invitation-status="DECLINED"],
<+calendar-month-day-box-item[invitation-status="DECLINED"] {
<+    opacity: 0.3;
<+}
(Assignee)

Comment 1

10 years ago
Created attachment 335533 [details] [diff] [review]
patch v. #1

This patch adds another css - rule and sets the opacity to all other eventboxes, by assigning a value of 0.99 and thus enforcing a layout for these boxes, too. This is not the most elegant solution, I know, but it seems to solve the problem. When I grepped over the calendar project afterwards I could even detect that other people had the same bright idea in similar contexts.
Philipp (or anybody else), if you know about a cleaner way to enforce layout, please let me know and I will try that. For the moment I am asking for review with the patch as it is.
Note: Setting an opacity of 1.0 was simply ignored and did not force a relayout (even with "!important" declaration), that's why I had to use 0.99 as an opacity value.
Assignee: nobody → Berend.Cornelius
Status: NEW → ASSIGNED
Attachment #335533 - Flags: review?(philipp)

Updated

10 years ago
Keywords: regression
(Assignee)

Comment 2

10 years ago
Created attachment 335994 [details] [diff] [review]
patch v. #2

My first patch introduced a slight ui change by assigning the opacity to a child element of the binding. I talked this over with Andreas who convinced me that this is not useful. This patch thus addes the opacity directly to the eventbox.
Attachment #335533 - Attachment is obsolete: true
Attachment #335994 - Flags: review?(philipp)
Attachment #335533 - Flags: review?(philipp)
Comment on attachment 335994 [details] [diff] [review]
patch v. #2

I don't know a better solution for now, r=philipp
Attachment #335994 - Flags: review?(philipp) → review+
(Assignee)

Comment 4

10 years ago
I checked in my patch on trunk and MOZILLA_1_8_BRANCH
->FIXED
(Assignee)

Updated

10 years ago
Status: ASSIGNED → RESOLVED
Last Resolved: 10 years ago
Resolution: --- → FIXED
Target Milestone: --- → 0.9

Comment 5

10 years ago
checked in lightning 2008090205 and sunbird 20080901 -> VERIFIED.
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.