502438 - During a drag session, the shadows don't always follow the cursor movement

Status: RESOLVED FIXED

(Calendar :: Calendar Frontend, defect)

Description

[Decathlon]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; it-IT; rv:1.9.0.11) Gecko/2009060215 Firefox/3.0.11
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.1pre) Gecko/20090702 Lightning/1.0pre Shredder/3.0b3pre

I can easily reproduce this bug for allday events in week view and with a bit more difficultly for every events in multiweek/month views.
When it happens in week view, it's annoying because the shadow persists even changing week, month or year, to delete the shadow, another drag and drop session must be done.
In multiweek/month view the shadow disappears scrolling the view.



Reproducible: Always

Steps to Reproduce:
I explain str for allday events in week view because is simpler reproduce the bug.

1. In week view create an *allday* event on a day and more *allday* events in the *next* day until the box for allday event is full e.g. on my system three events are needed (actually isn't necessary fill the box with events, but in this way is simpler);
2. press the mouse button on the single event, then move it inside his day box until the shadow appears;
3. without release the button, move the event on the other day full of events;
4. release the mouse button (over one of those events).

Actual Results:  
the event is now in the other day but his shadow is still in the previous one.
Now changing week, month, year or disable/enable calendars, the shadow doesn't disappear. The only way to delete it is to drag an event elsewhere so the shadow will follow the cursor movements.


Expected Results:  
the shadow should disappear after the drop.


The issue isn't reproducible if you drop the event an empty space of the other day (if there is) or if you drop over an event but before the cursor has passed on empty space of that day box, because in that case the shadow move itself on the new day before drop the event.

The issue is reproducible with exactly the same steps to reproduce in multiweek/month views for normal events and allday events, but in this case you have to move *quickly* the event over onother event of the next day.
In this case, though, the shadow disappears scrolling month/week view.

Comment 1

[Decathlon]

Attachment: Steps to reproduce

After the checkin of bug 476227, this bug has changed the final behavior, so I've changed the summary too.
Now, after a drag session, there isn't any persisting shadow, but during the drag session the behavior of the shadows is the same as described in comment #0.

Steps to reproduce (see also the screenshot)
1. in week view create an *all day* event;
2. drag the event to the day box next to the original one on the *right* side 
-> a shadow appears in the box;
3. move the cursor over the shadow;
4. move *horizontally* the cursor back the original day box (over the original event box) 
-> the shadow should follow the cursor on the original day box but doesn't happen, it remains in the day box on the right;
5. release the mouse button.
-> the shadow disappears

If you do the same s.t.r. but on the left side box, it's slightly more difficult to get the bug because it needs a slightly faster movement from left to right (step 4).

The issue is reproducible in multiweek/month view too, but it need a faster movement (again for step 4).

The same issue occurs when dragging over the shadows of a multi-day event i.e. you can move the cursor over all the shadows and event boxes from a day to every other without get any movement of the shadows (if the cursor moves over the shadows or event boxes without touching empty space of the day boxes).

Comment 2

[Martin Schröder [:mschroeder]]

This is still reproducible as described in comment#1 using Lightning 1.0b7.

Comment 3

[Martin Schröder [:mschroeder]]

Henry, it does not seem to be appropriate to mark a bug as RESOLVED FIXED without commenting which change (commit) or other bug report fixed the actual problem. I would suggest you use RESOLVED WORKSFORME and add a comment in which version of Thunderbird you have checked the behavior and found it working as expected.

Comment 4

[Henry Wilkes (they/them) [:henry-x]]

I think this was fixed in https://hg.mozilla.org/comm-central/rev/1a0dde254f65 because this bug is still present in 91. That patch cleaned up the event handlers, whilst the other patches since 91 didn't. But I'm not 100% sure.