FLUID-146: No drop target visual feedback when clicking on image or link at beginning of drag during drag-and-drop.

Description

When initiating a drag-and-drop operation, if one clicks on the image in the thumbnail or the link, the mouse movement listener on the drop targets do not appear to receive the mouse movement events. Hence, no drop marker is displayed, since its display is based on the position of the mouse over the drop target.

Comments

• Anastasia Cheetham commented 2007-12-20T11:00:33.000-0500

  This behaviour also occurs with other non-lightbox test cases, even when the user clicks on the actual element that is orderable.

  For example: markupExamples/reorderer/concrete/todo-list/sortable-styled-todo-list.html
  Even clicking on the list items that have no lists nested within them, and dragging over top of list items with no nested lists within them, the drop targets to not receive mouse movement events.

  Oddly, the abstract list test (markupExamples/reorderer/abstract/unordered-list.html) seems to work just fine.

  It is not clear why the mousemove events are disappearing, or who is swallowing them.

• Joseph Scheuhammer commented 2007-12-20T14:29:20.000-0500

  A follow up to the notion that the events are being "swallowed". It's not clear that they are.

  First, it may be a function of the event model capture and/or bubble phases. The mouse is over the avatar, which is in a part of the dom that isn't on the capture nor bubble path. It's possible that the mouse movement events are not being directed at the drop target at all. That is, it's not that they are being swallowed before the drop target gets a chance to handle them; it's that they will never get to the drop target.

  Secondly, we are using jQuery().bind(). It's not clear (to me, at least) what jQuery does with that vis-a-vis the capturing/bubbling of events, nor how it handles different browser event models.

  A possibility is to try using standard dom1 or dom2 calls to add a mouse movement listener directly to the drop target and see what happens. If the first point above is right, then adding a mouse movement listener shouldn't work either. If it does work, then there is something about how jQuery handles events that we need to understand better.

• Anastasia Cheetham commented 2007-12-20T15:14:40.000-0500

  Jonathan and I have confirmed that the avatar is what is the target of the mousemove event, when the cursor is indeed over the avatar. The next question is how to address this.

• Jonathan Hung commented 2007-12-20T16:32:19.000-0500

  By attaching the mousemove event handler to the avatar itself as well as to the droppable, the handler fires when we want it to.

• Justin Obara commented 2008-11-13T13:27:29.000-0500

  Appears to have been fixed