Closed
Bug 457854
Opened 16 years ago
Closed 16 years ago
Drag Shadow doesn't disappear after event resize
Categories
(Calendar :: Calendar Frontend, defect)
Tracking
(Not tracked)
VERIFIED
FIXED
1.0b1
People
(Reporter: informatique.internet, Assigned: gekacheka)
Details
Attachments
(1 file)
2.09 KB,
patch
|
berend.cornelius09
:
review+
|
Details | Diff | Splinter Review |
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...
Comment 1•16 years ago
|
||
Do you use Sunbird or Thunderbird + Lightning? What versions?
Reporter | ||
Comment 2•16 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
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•16 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•16 years ago
|
||
On linux i use gentoo-linux -> gnome + compiz
Reporter | ||
Comment 6•16 years ago
|
||
I can reproduce the "moving" bug either on win XP and linux, but the "resize" bug only on linux
Reporter | ||
Comment 7•16 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
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•16 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•16 years ago
|
||
(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)
Updated•16 years ago
|
Status: NEW → ASSIGNED
Hardware: PC → All
Reporter | ||
Comment 11•16 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•16 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+
Updated•16 years ago
|
Hardware: PC → All
Target Milestone: --- → 1.0
Comment 13•16 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•16 years ago
|
Status: ASSIGNED → RESOLVED
Closed: 16 years ago
Resolution: --- → FIXED
Comment 14•16 years ago
|
||
Checked in sunbird 20081021 and lightning build 20081021041724 and comment 11 -> VERIFIED
Status: RESOLVED → VERIFIED
Updated•14 years ago
|
Target Milestone: 1.0 → 1.0b1
You need to log in
before you can comment on or make changes to this bug.
Description
•