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
Forgot to mention build ID: Lightning 2006042506 Thunderbird: Trunk 2006042508.
Is this a regression from 0.1? If so, can someone provide a good regression range?
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
(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
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.
*** 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.
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.
Comment on attachment 224490 [details] [diff] [review] use correct view r=dmose
Attachment #224490 - Flags: first-review?(dmose) → first-review+
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.