Drag Shadow doesn't disappear after event resize

VERIFIED FIXED in 1.0b1

Status

Calendar
Calendar Views
VERIFIED FIXED
10 years ago
8 years ago

People

(Reporter: Hubert FONGARNAND, Assigned: gekacheka)

Tracking

Lightning 0.9
1.0b1

Details

Attachments

(1 attachment)

(Reporter)

Description

10 years ago
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?
(Reporter)

Comment 2

10 years ago
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
(Assignee)

Comment 3

10 years ago
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
(Reporter)

Comment 4

10 years ago
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
(Reporter)

Comment 5

10 years ago
On linux i use gentoo-linux -> gnome + compiz
(Reporter)

Comment 6

10 years ago
I can reproduce the "moving" bug either on win XP and linux, but the "resize" bug only on linux
(Reporter)

Comment 7

10 years ago
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
(Assignee)

Comment 8

10 years ago
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.
(Reporter)

Comment 9

10 years ago
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...
(Assignee)

Comment 10

10 years ago
Created attachment 341272 [details] [diff] [review]
v1 patch: multiday view event box: ensure mInMouseDown reset

(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
(Reporter)

Comment 11

10 years ago
Hi,

GREAT WORK!!!!

It works well now, no more annoying shadow... the view is much more usable now!
Hardware: All → PC

Comment 12

10 years ago
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

Comment 13

10 years ago
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.

Updated

10 years ago
Status: ASSIGNED → RESOLVED
Last Resolved: 10 years ago
Resolution: --- → FIXED

Comment 14

10 years ago
Checked in sunbird 20081021 and lightning build 20081021041724 and comment 11 -> VERIFIED
Status: RESOLVED → VERIFIED

Updated

9 years ago
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.