332772 - Drag n Drop on the edges of an event in Week Views messes up the event

Status: RESOLVED FIXED

(Calendar :: Sunbird Only, defect)

Description

[Manuel Vázquez Acosta]

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.0.1) Gecko/20060124 Firefox/1.5.0.1
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.0.1) Gecko/20060124 Firefox/1.5.0.1

Trying to move the start or end time of an event by dragging it top or bottom edges mess up the event. I have found this happens only in days with 1 or 2 events. Whether it has to do with bug 312736, I can't tell.

Reproducible: Always

Steps to Reproduce:
1. Drag the top or bottom edge of an event and drop it. There must be only 1 or 2 events in that day.

Actual Results:  
The dragged edge is aligned atop the start time of the first event in that day (maybe it self).

Expected Results:  
The dragged edge should stay at drop point (indicated while dragging with a time indication).

Plone Calendar Products crash with a 500 Internal Server Error when the event is modified this way. Maybe a result of the end time happening before start time.

Comment 1

[Manuel Vázquez Acosta]

Sorry, I forgot to state I checked this on last night build (20060404).

Comment 2

[Joey Minta]

(In reply to comment #0)
> Trying to move the start or end time of an event by dragging it top or bottom
> edges mess up the event. I have found this happens only in days with 1 or 2
> events. Whether it has to do with bug 312736, I can't tell.
I've heard other reports of this, but those have also been sporadic.  I'm particularly interested in what you can tell about what makes those 1 or 2 events that the bug happens with unique.  My guess would be that they have a timezone different from others in your calendar, but any information you can provide would be helpful.

Comment 3

[Joey Minta]

Attachment: consider tzs

The original drag code just cloned the column's date, so it always ended up in the default tz.  This was a minor-dataloss issue, so we now clone the original date of the item.  However, the current code didn't take into account the fact that the original date may have been in a different timezone than the view.  This patch adjusts for that possibility.

Comment 4

[Manuel Vázquez Acosta]

I will describe my environment as fully as posible.

I store my calendar remotely in a Plone Site (Plone Calendar product).
Yesterday I realized that I had to change my prefs to save date/times in UTC in order to Plone display them correctly. Otherwise they are show +5 hours ahead of my time.

I guess this can be a result of:
1. Or a bug in Plone Calendar Product.
2. The Plone Server being in a different TZ, and times being saved without my TZ indication when Sunbird is not configured to save in UTC. ISO 8601 states times without explicit TZ indication are to be interpreted as local time, but I think TZ indication for remote calendars must be mandatory. I can't recall if iCalendar enforces this. Do Sunbird always saves times with the TZ indication?


So, I change the pref, but then I had to edit and save some of my events to get them properly shown in the Plone Site. I can't asure I change all of my events, just the ones I thinks I'd like to be shown online correctly.

I will create a testbed calendar and report back whether or not this bug has to do with TZ.

Comment 5

[Michiel van Leeuwen (email: mvl+moz@)]

Comment on attachment 217286 [details] [diff] [review]
consider tzs

>Index: calendar/base/content/calendar-multiday-view.xml
>+          var sTimezone;
>+          var eTimezone;

Those varialbe names look like they have a prefix, just like mDate. I'd prefer to call them startTimezone, or startTz, to make it clear that they are just normal local variables, and not some special kind.

>+              if (this.mTimezone != newStart.timezone ||
>+                  this.mTimezone != newEnd.timezone) {

As discussed on irc, this is just an optimization. You could do the timezone tweaking always, but it is slow. So, please add a comment saying that it's an optimization.

r=mvl with that fixed.

Comment 6

[Joey Minta]

Patch checked in.

Comment 7

[Manuel Vázquez Acosta]

I was about to post a comment telling I wasn't been able to reproduce the bug on a brand new calendar created only to test this when I found it FIXED. 

I will download the nb to test with the "faulting calendar" on which I can reproduce the bug. In a couple hours I'll post back with a report.