326335 - New calendar not displayed in Lightning calendar tab after creation

Status: RESOLVED FIXED

(Calendar :: Lightning Only, defect)

Description

[Stefan Sitter [:ssitter]]

Faultily/confusing behavior of calendar tab in Lightning.

1. Start Thunderbird with clean profile and install Lightning.

2. Go to the calendar tab. 'Home' calendar is displayed.

3. Create a new calendar named 'test'.
   --> Error: The new calendar is created but is not shown in calendar tab. 
              Switching to other tabs or applications does not help.
       
(This worked in former versions on lightning.)

4. Double click on the space in calendar tab where the new calendar should be displayed.
   --> Confusing: The calendar properties for 'test' is shown, although it
       seemed that we clicked into empty space.

5. Select 'Home' calendar and press 'Delete' button
   --> The 'Home' calendar is deleted from calendar tab. 
       The 'test' calendar is now displayed in place of the 'Home' calendar.

5. Select 'test' calendar and press 'Delete' button
   --> The 'test' calendar is deleted from calendar tab. Error: 'Home 
       calendar is shown again? (This might be intended but is very confusing)

Expected results:
After calendar creation the new calendar is displayed in calendar tab.
(Not sure about the resurrected 'Home' calendar issue)

Tested on windows with Thunderbird 1.5 (20051201) and Lightning build from 2006-02-07.

Comment 1

[Stefan Sitter [:ssitter]]

Seems that the auto creation of 'Home' calendar is intended. Removing that issue from this bug.

New calendar not displayed in Lightning calendar tab after creation:

Works in Tb 1.5 (20051201) + lightning-win32-2006-02-02-07-mozilla1.8
Fails in Tb 1.5 (20051201) + lightning-win32-2006-02-03-06-mozilla1.8

Checkins between 2006-02-02 06:00 and 2006-02-03 06:00:
Bug 325476, Bug 324028, Bug 298349, Bug 325325, Bug 270995,
Bug 323953 <-- seems most suspect

Comment 2

[Stephan Schaefer]

Attachment: Triggers redraw of calendar tree.

In order to trigger a redraw of the calendar tree that will also access the rowCount property, we have to signalize that one line was added or removed. Using the index 0 for this operation guarantees correct relayout for the whole tree. An invalidate() is obsolete then and could in fact trigger a second redraw.

Comment 3

[Dan Mosedale (:dmosedale, :dmose)]

Comment on attachment 211161 [details] [diff] [review]
Triggers redraw of calendar tree.

mvl found a case where not calling invalidate() is going to cause problems (if row 0 is scrolled out of view).  So if you could leave the invalidate call, and update the overall comments to accurately reflect the current situation, that'd be great.

Comment 4

[Stephan Schaefer]

Attachment: Triggers redraw and invalidates. Just in case...

Added the invalidate call and some more comments. I think the old comment should stay as it indicates that something is still not ok here and it references a related issue.

Comment 5

[Dan Mosedale (:dmosedale, :dmose)]

Comment on attachment 211182 [details] [diff] [review]
Triggers redraw and invalidates. Just in case...

Interestingly, I can't reproduce this bug in my development trees.  However, this patch is clearly more correct than what's in the tree now, and since Stephan can reproduce this problem and it fixes it for him, I'll go ahead and land it.  Thanks for the patch, Stephan!

Comment 6

[Dan Mosedale (:dmosedale, :dmose)]

Fix checked in, with comment re-ordering for clarity.