533414 - In week view, the drag shadow of events that spanning multiple days, doesn't show the position of the whole event

Status: RESOLVED FIXED

(Calendar :: Calendar Frontend, defect)

Description

[Decathlon]

Reproducible:
Always


Steps to Reproduce:
1. in week view, set a sufficient number of visible hours (e.g. pressing more times "ctrl" + "-" keys) in order to see a large part of the view;
2. create a new events with the end date one day or some days after the start date.
3. try to drag and drop the event in the view on the same day or on another day by grabbing and moving the event on the first day, on the last day or on a day in the middle.


Actual Results:
the drag shadow covers only the grabbed part of the event (first day, last day or intermediate days) and doesn't span automatically on the others days moving the event on the same day over midnight.
A label shows either the start time or the end time only when the user grabs the start or the end part of the event but never both indications at the same time; no indication at all grabbing event in a middle part.


Expected Results:
while dragging, the shadow should cover the whole position and should automatically span on the others days dragging the event over midnight.
During the drag session, should always exist an information about both start and end time of the new position.

Comment 1

[Decathlon]

Attachment: [long,test] proposal

Proposal for fixing the issue.

I've added some methods to figure out the number of shadows in particular when start or end span over midnight.
They give the number of shadows, the offset between the first shadow and the selected one (that changes when the shadow spans over midnight), the start time and end time of the first and last shadows of the occurrence.
It's a bit large, don't know if there is some smarter (or safety) way to do it or if something must be different.
 
I haven't changed some particular (but useful) behaviors of the previous interface:
 - dragging the end of an event the mouse cursor can be moved over the lower limit of the view to set 0:00 as end time or a later one (that belong to the next day). The same behavior on the "start side" (upper limit of the view) isn't allowed.
 - in every day of the occurrence, the gripbars are active to set a new start/end time dragging the event starting from that day
 
When a click on the gripbars occurs, the patch figure out the new start/end time to show the drag-labels and the shadows, so, the patch fixes bug 370166 too.

I've tested a lot this patch and seems everything fine (hopefully ;-), but I might have missed something, therefore, if someone want to try it without build, to eventually find particular cases where the patch fails, I've uploaded a patched Lightning (the last Lightning nightly 1.0b1pre 20091210) here:

http://www.mediafire.com/file/mtjymxz4tuj/lightning1.0b1pre20091208031515_bug533414_linux.xpi

http://www.mediafire.com/file/qoigydy5rnm/lightning1.0b2pre20091210070307_bug533414_win32.xpi
 
(build ID is copied from file install.rdf;
both downloaded from ftp://ftp.mozilla.org/pub/calendar/lightning/nightly/latest-comm-1.9.1)

Comment 3

[Philipp Kewisch [:Fallen][📱📆]]

Comment on attachment 416996 [details] [diff] [review]
[long,test] proposal

The patch looks very good. There is one minor issue I noticed, but that may also have been broken before.

When you zoom out far enough (not all the way, there must be some scrolling area) and then drag the event past 00:00 of the day, then it doesnt show on the shadow of the previous day. This happens when dragging into the past and future. This may be what you were describing in the previous comment, not sure. Im fine with doing that in a different bug though.


The code itself looks fine, nothing to complain! You're doing a great job on these dragging bugs, keep it up!

r=philipp

Comment 4

[Philipp Kewisch [:Fallen][📱📆]]

Pushed to comm-central <http://hg.mozilla.org/comm-central/rev/866f48ad3385>

-> FIXED