392194 - Incorrect time and shadow is shown when draging an event in week/day view

Status: VERIFIED FIXED

(Calendar :: Calendar Frontend, defect)

Description

[Omar Bajraszewski]

I have found the issue with Sunbird 0.5 but I've reproduce it also with Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.7pre) Gecko/20070813 Calendar/0.7pre. Couldn't find any similar bugs.


After creating a four hour event I moved it to Sunday. Start time of modified event was on Sunday and end time on Monday following week. Then I clicked on it and moved to earlier hour. The shadow showed wrong duration i.e. one hour.

Steps to reproduce:
1) Switch to week view (Monday is first day of the week)
2) Create an event "meeting" (Wednesday 20:00-23:00)
3) Drag and drop it to Sunday ( new start time is 23:00)
4) Click on it and move to earlier hour---> look at the shadow

Result:
Shadow shows wrong duration

Comment 1

[Martin Schröder [:mschroeder]]

Confirmed with Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.7pre) Gecko/20070813 Calendar/0.7pre.

Comment 2

[Philipp Kewisch [:Fallen] [:📆][:🧩]]

Decathlon, since you were working on that other dragging bug, maybe this one interests you too?

Comment 3

[Decathlon]

Attachment: [checked in] patch

This patch should fix this issue and another one that actually I don't understand if it's a bug or a wanted behavior because the code has been written to work in this way: when you drag an event in the same day, you can't move it backward over 0:00 i.e. it's impossible to move the start time in the previous day. I don't know if there is a reason for this behavior, I haven't found a bug related to it, but I've changed it because working on this bug, the required changes are minimal and, if I don't miss something, it seems working without problems.

Comment 4

[Philipp Kewisch [:Fallen] [:📆][:🧩]]

Comment on attachment 408446 [details] [diff] [review]
[checked in] patch

Looks good. The other issue you mention is indeed a bug, thanks for fixing it.

Now all we need is that the shadow automatically spans multiple days when moving an event past midnight. Do we have a followup bug for that?



>+          // don't let mouse position go outside the window edges
>+          if (mousePos < 0) {
>+              mousePos = 0;
>+          }
>+          let pos = mousePos - dragState.mouseOffset;
This could be:

let pos = Math.max(0, mousePos) - dragState.mouseOffset;


>+              if (dragState.endMin > 1440) {
>+                  dragState.endMin = 1440;
>+              }
>+              if (dragState.startMin < 0) {
>+                  dragState.startMin = 0;
>+              }
>+
Same here:

dragState.endMin = Math.min(1440, dragState.endMin);
dragState.startMin = Math.max(0, dragState.startMin);

I'll change this before checkin.

Comment 5

[Philipp Kewisch [:Fallen] [:📆][:🧩]]

Pushed to comm-central <http://hg.mozilla.org/comm-central/rev/3d6970158465>
      and comm-1.9.1 <http://hg.mozilla.org/releases/comm-1.9.1/rev/f9d0d59c03f5>

-> FIXED

Comment 6

[Decathlon]

Reopened because there are a pair of issues in particular cases.

1. Events with start time at 0:00 and end time the day after or more days after:
dragging the event from the first day and move it to later hours, the shadow doesn't follow the movement like should do (since the event starts at 0:00).
 
2. Events with duration greater than 24 hours spanning over three or more days
   (i.e. that have at least a full day):
dragging the event from the full day and move it to earlier hour, the shadow has incorrect length because doesn't keep in count the event part after the full day.

Both issues are caused by the end minute used to figure out the shadow length.
I have a patch but I want testing a bit before attaching it.

(In reply to comment #4)
> 
> Now all we need is that the shadow automatically spans multiple days when
> moving an event past midnight. Do we have a followup bug for that?
> 

The shadow should also cover the whole event to show the right position when dragging events that spanning more days, but actually it covers only the event part in the day where drag session has started.
I haven't found a bug about this issue, I will file a new one.

Comment 7

[Decathlon]

Attachment: fix for issues in comment #6

The problem was the end date used to calculate the shadow size. With the real end date and the real start date of the occurrence that spans multiple days, it seems everything fine.
I've also reverted the behavior of the snap (the movement with 15 minutes rounded jump) like the previous code: always to the start side (even if it is in the other day where, for now, the shadow doesn't span).

Comment 8

[Philipp Kewisch [:Fallen] [:📆][:🧩]]

Comment on attachment 410660 [details] [diff] [review]
fix for issues in comment #6

Looks good, r=philipp

Comment 9

[Philipp Kewisch [:Fallen] [:📆][:🧩]]

Pushed to comm-central <http://hg.mozilla.org/comm-central/rev/e00dce0f3aaf>
and comm-1.9.1 <http://hg.mozilla.org/releases/comm-1.9.1/rev/779297b4cf98>

-> FIXED

Comment 10

[Omar Bajraszewski]

Verified with Mozilla/5.0 (Windows; U; Windows NT 6.1; pl; rv:1.9.1.5) Gecko/20091112 Lightning/1.0pre Thunderbird/3.0

Comment 11

[Decathlon]

(In reply to comment #4)
> Now all we need is that the shadow automatically spans multiple days when
> moving an event past midnight. Do we have a followup bug for that?

If it isn't a duplicate, I've just filed Bug 533414.

Comment 12

[Philipp Kewisch [:Fallen] [:📆][:🧩]]

These bugs are likely targeted at Lightning 1.0b1, not Lightning 1.0. If this change was done in error, please adjust the target milestone to its correct value. To filter on this bugspam, you can use "lightning-10-target-move".

Comment 13

[Philipp Kewisch [:Fallen] [:📆][:🧩]]

These bugs are likely targeted at Lightning 1.0b1, not Lightning 1.0. If this change was done in error, please adjust the target milestone to its correct value. To filter on this bugspam, you can use "lightning-10-target-move".