Closed Bug 535353 Opened 10 years ago Closed 10 years ago

When event start time=12:10 is dragged to start time=full hour then it is released at full hour +10min


(Calendar :: Calendar Views, defect, minor)

Not set


(Not tracked)



(Reporter: damian.publicemail, Assigned: bv1578)


(Whiteboard: [needed beta][no l10n impact])


(2 files)

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; pl; rv: Gecko/20091102 Firefox/3.5.5 (.NET CLR 3.5.30729)
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv: Gecko/20091108 Calendar/1.0pre

Event is not released at the same time which tip shows.

Reproducible: Always

Steps to Reproduce:
1. Create event with start time = 12:10 PM
2. Try to move this event using drag&drop to any full hour
Actual Results:  
Even calendar shows 12:00, when event is released by mouse it starts from 12:10 so 'offset' is not set to 0 minutes

Expected Results:  
Event should start from 12:00

If event starts from not full hour it is impossible to move it into full hour using drag and drop.
Attached image screenshot
moved event still has 10 minutes "offset"
I stumbled on this behavior when I wrote some patches for drag and drop in week view. I agree with you that it is an incoherent behavior because the event doesn't go in the exact position where the shadow and, more important, the time labels suggest, but on the other hand, the event has the same movement logical of the shadow that is with jumps of 15 minutes, so if you start from 12:10 you can move the event to xx:25 xx:40 xx:55 xx:10.

I wouldn't know what's the best behavior, whether keeping the offset or lose it moving to full hours (00, 15, 30, 45 minutes), but IMHO in both cases the shadow and the labels should show the exact future position of the event (i.e. if the event keep the offset, the shadow should too, or vice versa).
I think in this bug we should snap to full 15 minutes always, i.e do what the drag label suggests.

At some point we could investigate using modifier keys (i.e Ctrl) to allow moving the event by minutes, but lets do this in a separate bug.
Flags: blocking-calendar1.0+
Whiteboard: [not needed beta][no l10n impact]
Attached patch patchSplinter Review
Changed the total minutes to add to the date-time of the event in order to move it to full hours or 15 minutes multiples (the shadow position before dropping the event and the time showed by the labels).
The original code subtracts "origMinStart" to "lastStart" that are both multiples of 15 minutes, and don't keep in count the real starting time of the event.
Assignee: nobody → bv1578
Attachment #448010 - Flags: review?(Mozilla)
OS: Windows XP → All
Hardware: x86 → All
Comment on attachment 448010 [details] [diff] [review]

patch works fine.

Since you started to correct typos, maybe you could have a look at the comment paragraph at [1] also.


Attachment #448010 - Flags: review?(Mozilla) → review+
(In reply to comment #5)
> Since you started to correct typos, maybe you could have a look at the comment
> paragraph at [1] also.

Given the amount of errors (typos and grammatical) I'm used to do usually, I think I'm the last person that could correct something ;-).
In fact, the typo I corrected in this patch it's a my typo I did in another patch :-)

I would like to ask you a favour. Since I also have a patch for the issue in comment 3 (now bug 569120), and since I haven't an HG account to push this patch in the repository, could you please check-in this patch, obviously when you have time, so I can make an updated patch for bug 569120?
This time I'll ask the review to Philipp because it will need decision about the key modifier to use and about another bug that could collide with that one.

Thanks in advance Markus.
Keywords: checkin-needed
Pushed to comm-central <>
Closed: 10 years ago
Resolution: --- → FIXED
Target Milestone: --- → 1.0b2
Keywords: checkin-needed
Target Milestone: 1.0b2 → 1.0b3
Whiteboard: [not needed beta][no l10n impact] → [needed beta][no l10n impact]
You need to log in before you can comment on or make changes to this bug.