Closed Bug 392194 Opened 13 years ago Closed 10 years ago

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

Categories

(Calendar :: Calendar Views, defect, minor)

defect
Not set
minor

Tracking

(Not tracked)

VERIFIED FIXED

People

(Reporter: omarb.public, Assigned: bv1578)

Details

Attachments

(2 files)

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
Confirmed with Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.7pre) Gecko/20070813 Calendar/0.7pre.
Severity: normal → minor
OS: Windows XP → All
Hardware: PC → All
Summary: Incorrect time is shown when draging an event in week view → Incorrect time and shadow is shown when draging an event in week/day view
Decathlon, since you were working on that other dragging bug, maybe this one interests you too?
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.
Assignee: nobody → bv1578
Status: NEW → ASSIGNED
Attachment #408446 - Flags: review?(philipp)
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.
Attachment #408446 - Flags: review?(philipp) → review+
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
Status: ASSIGNED → RESOLVED
Closed: 10 years ago
Resolution: --- → FIXED
Target Milestone: --- → 1.0
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.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
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).
Attachment #410660 - Flags: review?(philipp)
Attachment #408446 - Attachment description: patch → [checked in] patch
Comment on attachment 410660 [details] [diff] [review]
fix for issues in comment #6

Looks good, r=philipp
Attachment #410660 - Flags: review?(philipp) → review+
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
Status: REOPENED → RESOLVED
Closed: 10 years ago10 years ago
Resolution: --- → FIXED
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
Status: RESOLVED → VERIFIED
(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.
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".
Target Milestone: 1.0 → 1.0b1
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".
You need to log in before you can comment on or make changes to this bug.