Components: Hammer.js overrides native drag&drop

[taffeldt]

Bug, feature request, or proposal:

Probably a bug. Might be a proposal. Not entirely sure.

What is the expected behavior?

You should be able to use native HTML5 drag&drop, at least on non-Material elements.

What is the current behavior?

The dragstart event gets overriden by Hammer.js, so you can't access required event properties like dataTransfer.

What are the steps to reproduce?

With Hammer.js installed, bind the dragstart event to a function and try to access dataTransfer. It will be undefined.
Alternatively uninstall Hammer.js and do the dame steps. You will get the error message: "Hammer.js is not loaded, can not bind dragstart event".
For the first case I set up a plunker right here: http://plnkr.co/edit/CMzTNi0HKVxI9xI3ztsc?p=preview Make sure to check console output once you start dragging the first div.

What is the use-case or motivation for changing an existing behavior?

Angular Material 2 should not prevent you from using native APIs on other tags.

Which versions of Angular, Material, OS, browsers are affected?

Tested with Angular 2.0.1, Material 2.0.0-alpha.9-3 and Hammerjs 2.0.8
All browsers should be affected. Tested with Firefox 49.0.1 and Chrome 53.0.2785.143

Is there anything else we should know?

Overriding dragstart should not be necessary during Hammerjs initilisation. The drag event contains all necessary information.
You can read the discussion on Reddit for additional information: https://www.reddit.com/r/Angular2/comments/56kh4g/html5_drag_drop/

[devversion]

This is because the MdGestureConfig is registering the drag event in Angular's event manager.

• hammer_gestures.ts#L55

It would be probably better to just have the slide event for now, because the drag event is not used by any component yet (only by the gestures demo)

[jimitndiaye]

@DevVersion I think the _drag_ event should be sufficient for gestures, if needed. _dragstart_ and dragend* are required for HTML5 drag and drop and should not be overridden.
MdGestureConfig#L11 should probably be modified to exclude them.

[jelbourn]

I agree that we shouldn't be clobbering the native drag events.

[william-lohan]

In the mean time, I found, you can add the following to app.module to revert to native drag events.

@Injectable()
export class AppGestureConfig extends HammerGestureConfig { }

@NgModule({
...
  providers: [{ provide: HAMMER_GESTURE_CONFIG, useClass: AppGestureConfig }],
...
})
export class AppModule {}

[ratscrew]

1025 is the same issue

[devversion]

@jimitndiaye I did not mean to remove the drag events, I just said that we could use the slide recognizer, because it's based on the drag recognizer (just with a smaller threshold) and does not interfere with the native DOM events.

Anyways it seems that dragend and dragstart are now removed in #1458

Personally I would have removed all drag _aliases_ for now, because those are not used by any component yet.

[jelbourn]

Closed via #1458

[kgiroux]

When this correction will be available ?

Sincerly

[mwamufiya]

@kgiroux in waiting for this change, I've manually updated the material.umd.js to remove the 2 events in conforming with the change that is pending as shown here merge

not ideal, but hopefully it helps if this is a blocker for you as it was for me.

[kgiroux]

@mwamufiya, I follow the advice from @gatimus. But it is just a temporary fix. It is just for having a date of release. Thank for your quick reply =)

[rajjaiswalsaumya]

Is this released ? Can we drag and drop rows in cdktables ?

[angular-automatic-lock-bot[bot]]

This issue has been automatically locked due to inactivity.
Please file a new issue if you are encountering a similar or related problem.

Read more about our automatic conversation locking policy.

_{_This action has been performed automatically by a bot._}