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

RESOLVED FIXED

Status

--
major
RESOLVED FIXED
13 years ago
13 years ago

People

(Reporter: sebo.moz, Assigned: jminta)

Tracking

({dataloss})

Trunk
x86
Windows XP
dataloss

Details

Attachments

(1 attachment, 1 obsolete attachment)

(Reporter)

Description

13 years ago
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
(Reporter)

Comment 1

13 years ago
Forgot to mention build ID: Lightning 2006042506
Thunderbird: Trunk 2006042508.
Severity: normal → major
Keywords: dataloss
(Assignee)

Comment 2

13 years ago
Is this a regression from 0.1?  If so, can someone provide a good regression range?
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]
Status: UNCONFIRMED → NEW
Ever confirmed: true
Version: unspecified → Trunk
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
(Assignee)

Comment 5

13 years ago
(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.
Assignee: nobody → jminta
(Assignee)

Comment 6

13 years ago
Created attachment 220866 [details] [diff] [review]
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.
Attachment #220866 - Flags: first-review?(dmose)
(Assignee)

Updated

13 years ago
Status: NEW → ASSIGNED
(Assignee)

Comment 7

13 years ago
*** Bug 335659 has been marked as a duplicate of this bug. ***
*** Bug 338622 has been marked as a duplicate of this bug. ***
Summary: Day view does not use timezone information → Day view does not work [no event dialog, no edit/delete, not using timezone information]
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.
Attachment #220866 - Flags: first-review?(dmose)
(Assignee)

Comment 10

13 years ago
Created attachment 224490 [details] [diff] [review]
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.
Attachment #220866 - Attachment is obsolete: true
Attachment #224490 - Flags: first-review?(dmose)
Comment on attachment 224490 [details] [diff] [review]
use correct view

r=dmose
Attachment #224490 - Flags: first-review?(dmose) → first-review+
(Assignee)

Comment 12

13 years ago
Patch checked in.
Status: ASSIGNED → RESOLVED
Last Resolved: 13 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.