Closed Bug 457854 Opened 16 years ago Closed 16 years ago

Drag Shadow doesn't disappear after event resize

Categories

(Calendar :: Calendar Frontend, defect)

Lightning 0.9
defect
Not set
normal

Tracking

(Not tracked)

VERIFIED FIXED

People

(Reporter: informatique.internet, Assigned: gekacheka)

Details

Attachments

(1 file)

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; fr-FR; rv:1.9.0.3) Gecko/2008092416 Firefox/3.0.3
Build Identifier: 

If you resize an event, and doesn't stop moving the mouse after releasing the button, the event get resized but the drag shadow is still shown until you click somewhere...

Reproducible: Always

Steps to Reproduce:
1. Start a resize procedure on an event
2. Move the mouse to the desired size
3. and release the mouse button while moving the mouse (without stopping)
Actual Results:  
The event get resized correctly but the drag shadow is still there and follow the mouse pointer while the button is not pressed...

Expected Results:  
The event get resized correctly, the drag shadow shoud disappear

The bug is very annoying for today use...
Do you use Sunbird or Thunderbird + Lightning? What versions?
I'm using thunderbird + Lightning 0.9.

I reproduce the bug using the MultiDay View (week view, or day view)
Version: unspecified → Lightning 0.9
I am not able to reproduce this with thunderbird 2.0.0.17 and lightning 0.9 on w2k sp4 (thunderbird version from Help | About).

I assume this is on Linux based on the user-agent in comment 0.
(If I'm wrong, feel free to set the OS back to 'other'.) 
In case it might be relevant: Which Linux, and which window manager?
OS: Other → Linux
Hi, i can't reproduce the problem when resizing on windows XP SP2
but it appears when moving an event...

Step to reproduce on windows:
1 : begin to drag the event by clicking on it
2 : release the mouse button outside the event (in another column) while moving the mouse

-> The event is not moved and the shadow is following the mouse...

May it's another bug we should open
I can post videos to explain the problem
On linux i use gentoo-linux -> gnome + compiz
I can reproduce the "moving" bug either on win XP and linux, but the "resize" bug only on linux
Sorry, i reproduce the bug on a win XP box too...

The bug is hardier to reproduce on windows (you have to reduce the size off an event)

To reproduce resize the event using the grip on the downside of the event
OS: Linux → All
I am now able to reproduce two ways:

A. gripbar
  1. click (do not drag) on grip bar, 
  2. then after releasing button, move mouse; 
  actual: drag shadow follows to mouse until leave pane or click on event again.
  expect: no drag shadow after releasing button

B. fast move
  1. select day other than day with event
  2. quickly drag event to another column and release button
  3. wave mouse over event
  actual: column becomes selected, then when waving mouse over event it picks up shadow.
  expect: drag event to new column, no shadow after releasing mouse button.
OK,
i've seen the 'click on the grip bar' bug too... it's the easiest to reproduce

Another precision : i'm using a caldav calendar and the bug is easier to reproduce when refreshing is slower...
(patch -l -p 1 -i file.patch)

For A (click gripbar), calendar-event-box mousedown should not set mInMouseDown.
(mouseup is not received, maybe because mousedown in gripbar starts drag shadown, and drag box intercepts events in stack.)
So mousedown now only sets mInMouseDown if whichside is false, indicating it is not in a gripbar.

For B (quick drag), added mouseout handler.  (mousemove is not received, maybe because move is so quick the next coordinates are outside the box.  waving mouse over event later finally triggers mousemove event, starting shadow.)

Summary:
So event box mInMouseDown is set in mousedown handler if not in a gripbar.
If mouse doesn't move (or <3px move), then it is reset by mouseup handler.
If mouse moves inside event box, mousemove handler starts drag shadow and resets mInMouseDown.
If mouse moves outside event box before mousemove, mouseout handler starts drag shadow and resets mInMouseDown.
Assignee: nobody → gekacheka
Status: UNCONFIRMED → NEW
Ever confirmed: true
Attachment #341272 - Flags: review?(Berend.Cornelius)
Status: NEW → ASSIGNED
Hardware: PC → All
Hi,

GREAT WORK!!!!

It works well now, no more annoying shadow... the view is much more usable now!
Hardware: All → PC
Comment on attachment 341272 [details] [diff] [review]
v1 patch: multiday view event box: ensure mInMouseDown reset

The issue was not easy to reproduce for me but I could clearly see that it resolves it. I think that the whole dragn'drop implementation in the multiday-view is a  workaround due to the irregularities of the old drag'n drop API. Looking at http://developer.mozilla.org/En/DragDrop/Drag_and_Drop
I can see that some new drag-events are defined in the new code-line that probably work better.

r=berend.
Attachment #341272 - Flags: review?(Berend.Cornelius) → review+
Hardware: PC → All
Target Milestone: --- → 1.0
patch pushed to comm-central: 
http://hg.mozilla.org/comm-central/rev/8ce2707a3de4

-> issue is fixed
Andreas also tested the patch before I checked it in.
Status: ASSIGNED → RESOLVED
Closed: 16 years ago
Resolution: --- → FIXED
Checked in sunbird 20081021 and lightning build 20081021041724 and comment 11 -> VERIFIED
Status: RESOLVED → VERIFIED
Depends on: 480481
No longer depends on: 480481
Target Milestone: 1.0 → 1.0b1
You need to log in before you can comment on or make changes to this bug.