Open Bug 1548949 Opened 9 months ago Updated 7 months ago

dataTransfer.dropEffect of dragend event randomly become non-"none" values when the dragged item is dropped on undroppable location

Categories

(Core :: DOM: Drag & Drop, defect, P3)

defect

Tracking

()

Tracking Status
firefox68 --- affected

People

(Reporter: yuki, Unassigned)

Details

Attachments

(2 files)

Attached file testcase.html

When there is no application acceptable to the drag data type, a "dragend" event for the case should be fired with "none" dataTransfer.dropEffect. Such a behavior is well-known and really used by Firefox itself to detach a tab dropped outside of the window. However, when such a data type is specified by an web contents or an addon, Firefox unexpectedly and randomly fires a "dragend" event with non-"none" dropEffect.

Steps to reproduce

  1. Open the attached testcase on a tab.
  2. Open web console for the tab.
  3. Drag any item (for example "item 6"). When you successfully start dragging the item will become green.
  4. Drop the item on anywhere outside of the content area, for example: the tab bar, the bookmarks toolbar, the console, or the desktop.
  5. Repeat steps 3 and 4 multiple times.

Actual result

Both "DRAG END move" and "DRAG END none" are logged.

Expected result

Only "DRAG END none" is logged.

Tested environments

  • Firefox 66.0.3 (64bit, e10s enabled) on Windows 10
  • Nightly 68.0.a1 (64bit, e10s enabled) on Windows 10
Attached file sidebar-example.xpi

This is another testcase, an example of sidebar addon. It is same to the initial testcase except tabs are listed in the sidebar.

This was originally reported as an issue of Tree Style Tab addon.

Please note that you may need to be careful to avoid the bug 1476195 when you try the sidebar addon example.

The priority flag is not set for this bug.
:enndeakin, could you have a look please?

For more information, please visit auto_nag documentation.

Flags: needinfo?(enndeakin)

It looks like the dropEffect is being updated from the parent for every drag event (most importantly dragexit). In the in-process case, nsContentUtils::SetDataTransferInEvent only sets it for dragenter/dragover/drop/dragend. For other drag events, the effect should remain as the default value for the DataTransfer type which is 'none'

The result isn't random though. It depends on the result of the last dragover event. If you dragged from the list outside the content frame, the last drop effect would be 'move'. But if dragged off the list first, the last drop effect is 'none.

Flags: needinfo?(enndeakin)
Priority: -- → P3
You need to log in before you can comment on or make changes to this bug.