Closed Bug 502438 Opened 15 years ago Closed 2 years ago

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


(Calendar :: Calendar Frontend, defect)

Lightning 1.0b7
Not set


(thunderbird_esr91 wontfix)

96 Branch
Tracking Status
thunderbird_esr91 --- wontfix


(Reporter: bv1578, Unassigned)



(Whiteboard: [fixed by bug 1713130])


(1 file)

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; it-IT; rv: Gecko/2009060215 Firefox/3.0.11
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv: 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.
Attached image 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).
Summary: After a drag and drop of an event over another event, sometimes the shadow doesn't disappear → During a drag session, the shadows don't always follow the cursor movement
This is still reproducible as described in comment#1 using Lightning 1.0b7.
Ever confirmed: true
OS: Windows XP → All
Hardware: x86 → All
Version: unspecified → Lightning 1.0b7
Closed: 2 years ago
Resolution: --- → FIXED

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.

Flags: needinfo?(henry)

I think this was fixed in 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.

Depends on: 1713130
Flags: needinfo?(henry)
Whiteboard: [fixed by bug 1713130]
Target Milestone: --- → 96 Branch
You need to log in before you can comment on or make changes to this bug.