335501 - Day view does not work [no event dialog, no edit/delete, not using timezone information]

Status: RESOLVED FIXED

(Calendar :: Lightning Only, defect)

Description

[Sebastian Schwieger]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8) Gecko/20060425 BonEcho/2.0a1
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8) Gecko/20060425 BonEcho/2.0a1

Creating an event in Timezone Europe/Berlin starting at 13.00 shows this event in day view starting at 11.00 . Week view and Month view show up correctly.

Reproducible: Always

Steps to Reproduce:
1.Create event starting 13.00
2.change to day view


Actual Results:  
event is starting at 11.00

Expected Results:  
obvious

Timezone Europe/Berlin is checked in Options

Comment 1

[Sebastian Schwieger]

Forgot to mention build ID: Lightning 2006042506
Thunderbird: Trunk 2006042508.

Comment 2

[Joey Minta]

Is this a regression from 0.1?  If so, can someone provide a good regression range?

Comment 3

[Stefan Sitter [:ssitter]]

I can confirm this bug but can't give detailed steps for reproduction until now. I'll try to find a regression range too.

During test for this with Tb 1.5.0.2 (20060426) and Ltn 0.1+ (20060426) I got the following errors with clean profile after switching from week to day view:

Error: this.calView.controller has no properties
Source File: chrome://calendar/content/calendar-multiday-view.xml
Line: 1782

Error: uncaught exception: [Exception... "'[JavaScript Error: "this.calView.controller has no properties" {file: "chrome://calendar/content/calendar-multiday-view.xml" line: 1782}]' when calling method: [calIOperationListener::onOperationComplete]"  nsresult: "0x80570021 (NS_ERROR_XPC_JAVASCRIPT_ERROR_WITH_DETAILS)"  location: "JS frame :: file:///<profile>/components/calCompositeCalendar.js :: anonymous :: line 432"  data: yes]

Comment 4

[Stefan Sitter [:ssitter]]

I think the errors in comment 2 are responsible for the display problems mentioned in this bug. When following this steps the event is displayed in UTC (or some random timezone) and not in the correct timezone and the errors from comment 2 are displayed:

1) Start Thunderbird with new profile, install Lightning, restart
2) Click a day in minimonth to get the month view displayed
3) Double click day and create an event
4) Select menu Calendar->Day View or toolbarbutton

WORKS with lightning-2006-04-14-08-mozilla1.8.xpi
FAILS with lightning-2006-04-15-08-mozilla1.8.xpi

Check ins during that time: Bug 330386, Bug 334069, Bug 311268

Comment 5

[Joey Minta]

(In reply to comment #4)
> I think the errors in comment 2 are responsible for the display problems
> mentioned in this bug. When following this steps the event is displayed in UTC
> (or some random timezone) and not in the correct timezone and the errors from
> comment 2 are displayed:
> 
> 1) Start Thunderbird with new profile, install Lightning, restart
> 2) Click a day in minimonth to get the month view displayed
> 3) Double click day and create an event
> 4) Select menu Calendar->Day View or toolbarbutton
> 
> WORKS with lightning-2006-04-14-08-mozilla1.8.xpi
> FAILS with lightning-2006-04-15-08-mozilla1.8.xpi
> 
> Check ins during that time: Bug 330386, Bug 334069, Bug 311268
> 

Gotta be Bug 330386, especially with the controller error.  That's me.  I'll look into it.

Comment 6

[Joey Minta]

Attachment: races suck

As near as I can tell, the problem is related to the new call to currentView() that was introduced by the bug previously cited.  It seems that asking for the selectedPanel actually requires the DOM for that panel to be laid out.  (I think.)

Then, when we set the displayCalendar(), because storage is so fast, the view asks for the events and it returns them and reaches onOperationComplete before we can set the controller, two lines later.  Without the DOM already being there, we gained some time in the race by laying that out, I believe.

Therefore, this patch moves the displayCalendar() call to the end, avoiding any potential race, since onOperationComplete won't be called until after everything has been set.

Comment 7

[Joey Minta]

*** Bug 335659 has been marked as a duplicate of this bug. ***

Comment 8

[Stefan Sitter [:ssitter]]

*** Bug 338622 has been marked as a duplicate of this bug. ***

Comment 9

[Dan Mosedale (:dmosedale, :dmose)]

Comment on attachment 220866 [details] [diff] [review]
races suck

Removing review flag until we have a better understanding of what's going on here, as per IRC discussion.

Comment 10

[Joey Minta]

Attachment: use correct view

OK, this patch fixes things properly.  Since currentView() returned the selectedPanel of a never before used deck, we got the first panel, which was the day view.  The problem was that we then didn't go grab the month-panel until later.  It was only a quirk in the view code that kept the error from appearing until later.  This patch makes sure that we work with the correct view when the minimonth is clicked.

Comment 11

[Dan Mosedale (:dmosedale, :dmose)]

Comment on attachment 224490 [details] [diff] [review]
use correct view

r=dmose

Comment 12

[Joey Minta]

Patch checked in.