432653 - All events in all views take the color of the last calendar in my calendars list

Status: VERIFIED FIXED

(Calendar :: Provider: GData, defect)

Description

[Ben Lerner]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9pre) Gecko/2008050606 Minefield/3.0pre
Build Identifier: TB 20080421, Lightning nightly (2008050621), GData nightly

This is a regression from yesterday's nightly (build available 2008-05-06).  Normally, all calendar events respect the colors of the calendar they're from.  Today, they're all the same color, and that color is taken from the last (bottommost) calendar in my calendars list.  If I change the color of that calendar, all events change colors to match; if I change any other calendar, nothing happens.

I don't know if it's the Lightning extension or the GData update that did it (I use the Lightning Nightly Updater to update them both), as all of my data are in Google calendars...

Reproducible: Always

Comment 1

[Ben Lerner]

Edited to add: Confirmed also on Thunderbird version 3.0a1pre (2008050503), and was working in Lightning 2008050604.

Comment 2

[Martin Schröder [:mschroeder]]

I can't reproduce, but I have no Google Calendar in my calendar list. So, maybe it's a "Provider:GDATA" problem and no "Calendar View" one.

Comment 3

[Ben Lerner]

I just created a local calendar, and tried adding an event to it.  That failed, in a weird way: it created the event in the last (bottommost) calendar on my list, which is a read-only Google calendar!  So that event was non-editable, and triggered an error (because the calendar was, of course, read only).  So it seems to be some interaction of the views and the GData provider...

Comment 4

[Philipp Kewisch [:Fallen][☁️📆]]

Ben, if you remove the gdata calendar(s) from your list, do you still have this problem? Did I understand correctly, that all of your calendars are Google Calendars? If so, add a different calendar inbetween.

I'll test this soon, I did some large changes to the gdata provider, so regressions are expected ;-)

Comment 5

[Ben Lerner]

OK, new test procedure:

1) Using TB2.0.0.14, create a blank profile, add Lightning Nightly Updater, and get the latest versions of Lightning and GData.

2) Create two local calendars (red and blue), add a Google calendar (yellow), and then a third local calendar (green)

3) Create events on all four calendars.

In this test scenario, colors worked correctly, for all four calendars.

In my normal profile, I have the following calendars:
* A read-only ICS calendar
* A read-only local calendar (r/o for convenience)
* Five GData calendars
* Four read-only Google calendars (originally just ICS, but GData offered to update them, so I did.  Philipp, the UI for that bit was a little confusing, but it worked so I'm not worried :-)

In the TB3 test profile, I have nearly the same calendars as above, in a slightly different order:
* A local calendar
* Four r/o Google calendars (the same four as above)
* A r/o ICS calendar (same as above)
* Five GData calendars (the same five as above)

In both of those profiles, the colors all go to the last calendar in my list -- read-only or not.  Also, creating a new event sticks it in the last calendar on the list -- read-only or not.  An interesting corollary of this: when the event has an alarm, dismissing the alarm fails with error number CAL_IS_READONLY, as you might expect.  Publishing the event fails too, because I don't have write access to that calendar.  Temporarily marking the calendar as writable lets me delete the event and fix things.

Hope that helps...

Comment 6

[Ben Lerner]

Philipp, as a minor aid in debugging -- would it be possible to include the build id into the description, the way Lightning does?  I feel bad saying above "Lightning nightly 2008050621 and GData nightly...to match", as it might make extra work for you :-p

Comment 7

[Dmitry Kagan]

Hi,

I can confirm this bug with the latest Lightning and Gdata provider nightly builds from 08-May-2008.

I've upgraded from Lightning 0.8 release version due to a different bug and I've encountered this problem when adding my Gdata calendars. After every new calendar, all events from all other Gdata calendars are displayed using the color I've chosen for the last Gdata calendar.

Comment 8

[klint]

Confirmed here.
More than displaying the events with the last GData calendar's color: if you edit the event, the event is shown as BELONGING to the last calendar (although this is not true on https://www.google.com/calendar).

Comment 9

[Stefan Sitter [:ssitter]]

Confirming bug per comment #7 and #8.

Regression range per comment #0 and #1: 
    Works in Lightning (2008050604) and corresponding gdata build
    Fails in Lightning (2008050621) and corresponding gdata build

Checkins during regression range: http://tinyurl.com/3hm7ov

Caused by Bug 430254?

Comment 10

[klint]

Not happening anymore (for instance in 20080517 build).
Philip, do you confirm that it has been fixed?
Thanks

Comment 11

[Ben Lerner]

I just updated to the latest nightly, and still see the problem with my calendars...

Comment 12

[Dmitry Kagan]

Same here. Latest nightly still has the problem.

Comment 13

[klint]

OK. One thing I have done since the last time I noticed the bug was to turn caching *on* for all my remote google calendars. Maybe this had an impact.

Comment 14

[Ben Lerner]

Interesting...  I turned caching on for two of my (read-only, google) calendars and restarted TB...and those two calendars promptly refused to show *any* of their events!  Unchecking caching brought the events back. 

Comment 15

[Philipp Kewisch [:Fallen][☁️📆]]

Attachment: Fix - v1

The problem was that the objects in addItem_response was static, on each new calendar the same object was used and the calendar object was therefore changed.

Comment 16

[Philipp Kewisch [:Fallen][☁️📆]]

Attachment: Fix - v1 (no whitespaces)

Version without whitespace changes.

Comment 17

[Daniel Boelzle [:dbo]]

Comment on attachment 321600 [details] [diff] [review]
Fix - v1

r=dbo

Comment 18

[Philipp Kewisch [:Fallen][☁️📆]]

Checked in on HEAD and MOZILLA_1_8_BRANCH

-> FIXED

Comment 19

[Ben Lerner]

Confirmed fixed with latest nightly.  Thanks Philipp!

Comment 20

[Martin Schröder [:mschroeder]]

VERIFIED per comment#19