User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; pl; rv:126.96.36.199) Gecko/20061204 Firefox/188.8.131.52 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?
(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: 12 years ago
Resolution: --- → WORKSFORME
Status: RESOLVED → VERIFIED
Component: Provider: WCAP → General
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.
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
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.
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+
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)
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+
Checked in on HEAD and MOZILLA_1_8_BRANCH -> FIXED
Status: ASSIGNED → RESOLVED
Last Resolved: 12 years ago → 11 years ago
Resolution: --- → FIXED
Verified with lightning 2007082405/lightning-wcap and Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:184.108.40.206pre) Gecko/20070824 Calendar/0.7pre
Status: RESOLVED → VERIFIED
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.
(In reply to comment #13) Decathlon, sounds like you are seeing the same issue as reported in Bug 357112.
(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.