Moving an event with timezone enabled via drag&drop changes time

VERIFIED FIXED in 0.7

Status

Calendar
Calendar Views
--
major
VERIFIED FIXED
11 years ago
10 years ago

People

(Reporter: Omar Bajraszewski, Assigned: Fallen)

Tracking

unspecified
Bug Flags:
blocking-calendar0.7 +

Details

Attachments

(2 attachments)

(Reporter)

Description

11 years ago
User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; pl; rv:1.8.1.1) Gecko/20061204 Firefox/2.0.0.1
Build Identifier: 

When I move an event that has timezone enabled using drag&drop method time changes

Reproducible: Always

Steps to Reproduce:
1.Create a new event and enable timezone for it
2.Save it
3.click on the event and move it to another day
Actual Results:  
Time of the event changes

Expected Results:  
Time doesn't change

Thunderbird version 2 beta 1 (20070113)
Lightning build 2007011605
WCAP enabler build 20070116
Omar, is this with a calendar on WCAP or with a local or other remote calendar and the prototype event dialog?
(Reporter)

Comment 2

11 years ago
(In reply to comment #1)
> Omar, is this with a calendar on WCAP or with a local or other remote calendar
> and the prototype event dialog?
> 

It was with a local calendar and with the prototype event dialog. Now I can't reproduce the problem- the prototype has been changed and now I can't enable timezone for it---> marking as WFM
Status: UNCONFIRMED → RESOLVED
Last Resolved: 11 years ago
Resolution: --- → WORKSFORME

Updated

11 years ago
Status: RESOLVED → VERIFIED
Component: Provider: WCAP → General
(Reporter)

Comment 3

11 years ago
Created attachment 256653 [details]
Flash movie presenting the problem

Please reopen the bug

Ligntning wcap 27/02/2007 (mozilla 1.8)
Thunderbird version 2.0pre (20070227)
Status: VERIFIED → UNCONFIRMED
Resolution: WORKSFORME → ---
Summary: Moving an event with timezone enabled via drag&drop changes time → [proto] Moving an event with timezone enabled via drag&drop changes time
Severity: normal → major
Status: UNCONFIRMED → NEW
Ever confirmed: true
QA Contact: wcap-provider → general
Taking this one.
Assignee: nobody → michael.buettner
I tried to reproduce this bug and it still occurs. I didn't have a look on the code, but it is clear that is has nothing to do with the dialog, it is a problem of the views. An event always has a timezone (as it always has a start/end-date), the prototype event dialog simply allows to display and eventually change the timezone. The problem will also show up for foreign (aka imported events).

I suspect that the problem happens if an event with a different timezone than the OS timezone gets modified via drag'n'drop. As the attached movie shows it doesn't happen with "Africa/Ceuta" set as timezone (which I assume has the same UTC offset as the timezone Omar has set in his OS). The same is true for me, since "Africa/Ceuta" has the same offset as "Europe/Berlin". As soon as I set the timezone to any other with a different UTC offset this bug shows up.
Component: General → Calendar Views
I tried to reproduce this bug and only succeeded in multiweek and month view.
Flags: blocking-calendar0.7?
OS: Windows XP → All
Hardware: PC → All
Summary: [proto] Moving an event with timezone enabled via drag&drop changes time → [Proto] Moving an event with timezone enabled via drag&drop changes time

Comment 7

11 years ago
According to Comment #5 this has nothing to do with the dialog. Therefore I think this might be the same issue/cause as reported in e.g. Bug 369331, Bug 381439 and Bug 390100.
Assignee: michael.buettner → nobody
Summary: [Proto] Moving an event with timezone enabled via drag&drop changes time → Moving an event with timezone enabled via drag&drop changes time
We decided on the QA chat this bug is serious enough to block 0.7 (changes event time and has already 3 duplicates).
Flags: blocking-calendar0.7? → blocking-calendar0.7+
(Assignee)

Comment 9

10 years ago
Created attachment 277298 [details] [diff] [review]
Fix dragdop handler

The problem was that the month view used the startDate and the new box's date to calculate the time difference. Together with the fact that libical's subtractDate is broken, this probably produced a one hour offset.

What I did to fix this is to calculate the difference by subtracting the dates of the source and target box, which gives full N-day intervals when dragging.

I also went ahead and made the function I changed to be four spaced and correctly indented, but I'm attaching the diff -w version, to make it easier to review. Alignment is of course correct in the real patch. I don't mind if we change everything at once, but since thats a lot of work I think its fine to do the style changes when a function is changed and the coder feels like it.
Assignee: nobody → philipp
Status: NEW → ASSIGNED
Attachment #277298 - Flags: review?(daniel.boelzle)

Updated

10 years ago
Attachment #277298 - Flags: review?(daniel.boelzle) → review?(michael.buettner)
Comment on attachment 277298 [details] [diff] [review]
Fix dragdop handler

works like a charm, clean and elegant solution to the problem -> r=mickey.
Attachment #277298 - Flags: review?(michael.buettner) → review+
(Assignee)

Comment 11

10 years ago
Checked in on HEAD and MOZILLA_1_8_BRANCH

-> FIXED
Status: ASSIGNED → RESOLVED
Last Resolved: 11 years ago10 years ago
Resolution: --- → FIXED
(Assignee)

Updated

10 years ago
Target Milestone: --- → 0.7
(Reporter)

Comment 12

10 years ago
Verified with lightning 2007082405/lightning-wcap and Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.7pre) Gecko/20070824 Calendar/0.7pre
Status: RESOLVED → VERIFIED

Comment 13

10 years ago
Hi,
on Sunbird 0.7 and Lightning 0.7 (and nightly build 0.8 12/8/2007) I always reproduce this issue if I try to drag a *multy-day* event (and not a single-day event) draging it by a day that isn't the first of the sequence.
When I drop the event, it jumps on a random day in the past, often the week previous, sometimes some days.
If I drag a multy-day event by the first day, the issue disapear and the new position is *always* correct.
I reproduce this with month view or mutliweek view.

The calendar is local; time zone is Europa/Rome; no others remote calendars are 
used. My OS is WinXP SP2.

Comment 14

10 years ago
(In reply to comment #13)
Decathlon, sounds like you are seeing the same issue as reported in Bug 357112.

Comment 15

10 years ago
(In reply to comment #14)
> Decathlon, sounds like you are seeing the same issue as reported in Bug 357112.
You're rignt. I searched on it, found several issue but not the right one so I posted here (a similar issue).
Sorry for that. Feel free to delete the post.

You need to log in before you can comment on or make changes to this bug.