Closed Bug 388985 Opened 17 years ago Closed 17 years ago

Calendar color not applied in views - events are translucent

Categories

(Calendar :: Lightning Only, defect)

x86
Windows 2000
defect
Not set
normal

Tracking

(Not tracked)

VERIFIED FIXED

People

(Reporter: ssitter, Assigned: Fallen)

References

Details

(Keywords: regression)

Attachments

(2 files, 2 obsolete files)

Default calendar color not applied in views - events are translucent

Steps To Reproduce:
1. Start Thunderbird with clean profile, install Lightning and restart
2. switch to calendar mode and create new event in default calendar

Actual Results:
Events are translucent

Expected Results:
Events use the default calendar color (light blue)

Regression range:
WORKS in Lightning 0.7pre (2007-07-19-04)
FAILS in Lightning 0.7pre (2007-07-19-10)

Works fine in Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8.1.6pre) Gecko/20070720 Calendar/0.7pre
This cleared itself for me, when I selected each calendar. I can't tell if this is temporarily for the session, or for long.
no it is not temporarily for the sessiononly. After I restarted thunderbird the colors were gone. But yes if you selct the calender, the colors reappear
Checkins between 2007-07-19 04:00 and 2007-07-19 10:00 :
    Bug 385900 (and Bug 380376) [http://tinyurl.com/2fqonx]
Blocks: 385900
Correction: This also applies to user defined calendar colors and not only to the default one.
Summary: Default calendar color not applied in views - events are translucent → Calendar color not applied in views - events are translucent
Flags: blocking-calendar0.7+
I just tried to reproduce this bug but had no luck. Could please anybody supply a list with steps that lead to this problem?
there are no steps to get this for me. If I start Lightning, the events are colorless.
I use Lightning 0.7Pre build 2007072204 with TB Portable 2.0.0.4 on Windows XP Professional.
I can only reproduce this issue when I add an new category to the events.

My steps to reproduce:

1. Start Thunderbird with clean profile, install Lightning and restart
2. switch to calendar mode and create new event in default calendar
3. open the category dialog, add a new category and use this one for the event
4. save the event -> all events are translucent.

Error Console:

Warning: Expected color but found 'null'.  Error in parsing value for property 'background-color'.  Declaration dropped.
Source File: chrome://calendar/content/preferences/editCategory.xul
Line: 0

Same for me with Lightning 2007072403 with TB version 2.0.0.5pre (20070723) on Win XP Pro as described in #7: No special steps necessary, just restart TB and all colors are gone. The error console does not show any color-related entries. 
Select a calendar and the related events are shown in the correct color (until next restart).
If I "color" my events by selecting the calendars, the colors remain even if I create a new event in a new category as described in #8 although I also get the message 

Warning: Expected color but found 'null'.  Error in parsing value for property 'background-color'.  Declaration dropped.
Source File: chrome://calendar/content/preferences/editCategory.xul

in the error console.
(In reply to comment #10)
> Warning: Expected color but found 'null'.  Error in parsing value for
>  property 'background-color'.  Declaration dropped.
> Source File: chrome://calendar/content/preferences/editCategory.xul

Just ignore this warning. It's not related to the issue reported here and there is already an open bug for the warning.
Same for me with Lightning 2007072403 with TB version 2.0.0.5 (20070716) on
Win XP as described in #7.
The color comes back when I click on a calendar in the calendars tab.
This may help in determining what is causing this: If you attempt to go back to 2007071603, as I did, this problem continues to occur.
In combination with this there is also one more thing that is very strange. The calendar view also appears in the mail view. I'll try to explain the steps:

start t-bird. go to calender view. now select every calendar so all the colors reappear. go back to mail view. switch to a different program (for instance firefox ;-), now go back to t-bird, and the mail view now includes the left sidebar with all the mail folders, and also the calendar view, instead of the e-mail pane.....

I hope this is a bit clear, otherwise see attachment 273815 [details]
(In reply to comment #15)
Patrick, you are seeing Bug 389288.
Berend, I'd like you to take a look at this if possible because this was caused by your checkin for Bug 385900.
thanks, that is indeed the bug, unfortunately I could not find it...
(In reply to comment #6)
> I just tried to reproduce this bug but had no luck. Could please anybody supply
> a list with steps that lead to this problem?
> 
I get this failure after I uninstalled wcap with fixed Bug 386589.
So I installed lightning-wcap and everything was okay.
Then I uninstalled wcap again and this Bug was back.

Hope it helps!
I finally managed to reproduce this bug (thanks to Andreas for trying out the obvious). I couldn't believe that it all depends on the 'prototypes'-pref, but it does. Setting the pref to false immediately shows the above described behavior. With having it set to true, everything works like a charm. So, the question remains what the heck is going on?

The landing of the Today Pane also played in important role in revealing this bug. It has to do with where the agenda gets overlayed. The agenda has been overlayed into messenger-overlay-sidebar.xul before the Today Pane came along and changed this to make it overlay today-pane.xul. I tracked it to this specific line of code that caused this problem.

Basically, to make a long story short, it all depends on where getCalendarManager() gets called. The colors for the calendar items gets initialized in updateStyleSheetForObject() which is called from an observer in the calICalendarManager implementation, see [1] for the code location. This function updates the stylesheets that contain the color information, which gets called depending on *when* getCalendarManager() gets called for the first time. So, it's basically a timing issue, which is a really bad thing. We shouldn't depend on the order in which specific objects enter life, this can't be the case in a robust application.

[1] http://lxr.mozilla.org/mozilla1.8/source/calendar/lightning/content/calendar-management.js#60
Attached patch preliminary patch (obsolete) — — Splinter Review
This patch fixes the bug, but the fix itself is just an ugly hack (as it was before). Basically, it just works because an early call to getCalendarManager() triggers a side-effect. A clean solution would probably be to iterate the calendars and call updateStyleSheetForObject() explicitly on them.

Daniel, what's your opinion on that?
Attachment #273979 - Flags: review?(daniel.boelzle)
Daniel and I, we finally tracked down what's going on here. Basically, it's one large giant side-effect that actually gets the views going. I'm going to summarize the different bits and pieces.

First of all, we have calendar-management.js [1], which hooks the load event of the document. The function that gets called is named "getCalendarManager()", which is defined in calendar-management.js. This is unfortunate at best, since it asks for trouble by clashing with the function in calUtils.js. The only difference between these functions is that the one in calendar-management.js registers a calICalendarManagerObserver observer in addition to get the implementation of calICalendarManager going.

In essence, calling getCalendarManager() [the function in calendar-management.js] instantiates the calendar manager *and* registers a calICalendarManagerObserver observer.

Now to a totally unrelated part of the application, setAgendaTreeView() in agenda-tree.js, see [3]. This is hooked up to the load event of the document and calls getCompositeCalendar() during execution. This function also resides in calendar-management.js, see [4]. Actually it exists twice, once for Sunbird and once for Lightning. This detail left apart, the important call is setting the prefPrefix, see [5]. Besides setting the pref, it notifies all observers.

Now, depending on whether or not the observer in calendar-management.js has been registered before or after this call, we're updating the necessary stylesheets that the views rely on. So, it all boils down to the order in which getCalendarManager() and getCompositeCalendar() are getting called. Pfuh...

All of this was revealed because the Today Pane changed the order in which the load events are getting fired *and* the wcap-pref changes the order of the above mentioned calls. Unfortunate, at least...

Part of the solution is to explicitly initialize the views, which basically doesn't happen. They are sitting there, waiting that side-effects call their update functions that are wired into observers. I'll come up with a patch as soon as possible. If somebody else wants to write a patch, this would be more than welcome.

[1] http://lxr.mozilla.org/mozilla1.8/source/calendar/lightning/content/calendar-management.js
[2] http://lxr.mozilla.org/mozilla1.8/source/calendar/lightning/content/calendar-management.js#173
[3] http://lxr.mozilla.org/mozilla1.8/source/calendar/lightning/content/agenda-tree.js#587
[4] http://lxr.mozilla.org/mozilla1.8/source/calendar/lightning/content/calendar-management.js#159
[5] http://lxr.mozilla.org/mozilla1.8/source/calendar/lightning/content/calendar-management.js#165
Attachment #273979 - Attachment is obsolete: true
Attachment #273979 - Flags: review?(daniel.boelzle)
This bug may be fixed after bug 388405 is resolved, since it changes the way the calendar manager is initialized.
Depends on: 388405
Assignee: nobody → philipp
Status: NEW → ASSIGNED
Unfortunatly, this is *NOT* fixed by the unify calendar list patch. I can still reproduce with the patch applied. So the question is, how should this be fixed without getting messy?

A spontaneous idea I had was to fire an event á la "calendarManagerLoaded" at the window, so that other pieces of code like the agenda or today pane can be sure that everything is initialized correctly.

I haven't quite gotten through understanding the whole extent of this, so I'm not sure the above idea will fix the problem.  Reassigning to nobody until I have an idea what I'm doing.
Assignee: philipp → nobody
Status: ASSIGNED → NEW
After talking to mickey in IRC, we have found a solution. It will be contained in the patch to bug 388405.

Assignee: nobody → philipp
This works for me again using Lightning 0.7pre (2007081505) with Thunderbird 2.0.0.7pre (20070815) on Windows 2000. FIXED by checkin for Bug 388405.
Status: NEW → RESOLVED
Closed: 17 years ago
Resolution: --- → FIXED
Target Milestone: --- → 0.7
I checked this at linux (build 2007081503) -> task is fixed. So I mark this issue as verified.
Status: RESOLVED → VERIFIED
I checked this issue again and this issue was not fixed with thunderbird 2.0.0.6 or tb 1.5.0.13. So I reopen this but. 
Status: VERIFIED → REOPENED
Resolution: FIXED → ---
There is something about categories that seems wrong in Lightning.  After I install today's nightly into a clean profile, create a new event, and click on the category dropdown, I see all the predefined categories (from "Anniversary" to "Vacation").  However, when I go to "Tools > Options > Lightning > Categories", I only see one category (which is blank and has the color "None").

Perhaps this is related to the problem.
(In reply to comment #28)
I saw this too but only for the default calendar color but not for calendars with custom color. It was fixed after restart resp. open calendar properties once. I think this is the reason why Bug 392173 was filed.

(In reply to comment #29)
This is due to Bug 393202.
Attached patch setting color (obsolete) — — Splinter Review
I could reproduce it by simply removing my storage.sdb, starting up, then creating an event. Quick & dirty fix for that setting the default color; Philipp may know a cleaner fix.
Attachment #280044 - Flags: review?(philipp)
Attached patch Cleaner fix — — Splinter Review
Less hacky, works :)
Attachment #280044 - Attachment is obsolete: true
Attachment #280688 - Flags: review?(michael.buettner)
Attachment #280044 - Flags: review?(philipp)
Comment on attachment 280688 [details] [diff] [review]
Cleaner fix

A much, much cleaner fix for the problem. Works as advertised and the code looks fine to me -> r=mickey.
Attachment #280688 - Flags: review?(michael.buettner) → review+
Checked in on HEAD and MOZILLA_1_8_BRANCH

-> FIXED
Status: REOPENED → RESOLVED
Closed: 17 years ago17 years ago
Resolution: --- → FIXED
Checked in Lightning(build 2007091703) and Sunbird (build 20070917) -> VERIFIED
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: