New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Allow for dom handlers only of HammerJS events #19604

Closed
milung opened this Issue Oct 7, 2017 · 0 comments

Comments

Projects
None yet
3 participants
@milung

milung commented Oct 7, 2017

I'm submitting a Feature Request


[ ] Regression (a behavior that used to work and stopped working in a new release)
[ ] Bug report  
[x ] Feature request
[ ] Documentation issue or request
[ ] Support request => Please do not submit support request here, instead see https://github.com/angular/angular/blob/master/CONTRIBUTING.md#question

Current behavior

When listening to the HammerJS events (e.g. 'tap') the listener is automatically added to the HammerManager instance. This leads to the issue if you want to listen to the same HammerJS event on nested element as there is no possibility to control propagation of the events and HammerManager of the parent elements can handle the event before the nested elements (In my case I need to use Renderer2.listen method). The HammerJS support the option "domEvents", but that has no effect as the event registration is always routed to the HammerGesturePlugin:

angular/packages/platform-browser/src/dom/events/hammer_gestures.ts

addEventListener(element: HTMLElement, eventName: string, handler: Function): Function {
const zone = this.manager.getZone();
eventName = eventName.toLowerCase();

return zone.runOutsideAngular(() => {
  // Creating the manager bind events, must be done outside of angular
  const mc = this._config.buildHammer(element);
  const callback = function(eventObj: HammerInput) {
    zone.runGuarded(function() { handler(eventObj); });
  };
  mc.on(eventName, callback); // <<<<
  return () => mc.off(eventName, callback); // <<<<
});

}

Expected behavior

Enable an option on HammerGestureConfig that will use domEvents of HammerJs and will register callback at dom element to enable bubling and propagation control of touch events.

A workaround to achieve that behavior is possible but not obvious with custom HammerGestureConfig:

export class GraphedHammerConfig extends HammerGestureConfig {

buildHammer(element: HTMLElement): HammerInstance {

const mc = new Hammer(element);

mc.set({enable: true, domEvents: true});

mc.on = (eventName, handler) => element.addEventListener(eventName, handler as any); // <<<<
mc.off = (eventName, handler) => element.removeEventListener(eventName, handler as any); //<<<<

return mc;

}
}

It would be preferable if the event is registered to the do element directly in HammerGesturePlugin if the HammerGestureConfig specifies domEvents options.

Minimal reproduction of the problem with instructions

register 'tap' listener in parent and child elements using Renderer2.listen method

What is the motivation / use case for changing the behavior?

There is possible woraround as mentioned above, but the current behavior is unexpected if you are assuming that touch events are handled in similar way as dom events.

Environment


Angular version: 4.4.2


Browser:
- [ x] Chrome (desktop) version 61.0.3163.100 
- [ ] Chrome (Android) version XX
- [ ] Chrome (iOS) version XX
- [ ] Firefox version XX
- [ ] Safari (desktop) version XX
- [ ] Safari (iOS) version XX
- [ ] IE version XX
- [ ] Edge version XX
 
For Tooling issues:
- Node version: XX  
- Platform:  

Others:

@ngbot ngbot bot added this to the Backlog milestone Jan 23, 2018

JiaLiPassion added a commit to JiaLiPassion/angular that referenced this issue Feb 2, 2018

JiaLiPassion added a commit to JiaLiPassion/angular that referenced this issue Feb 2, 2018

JiaLiPassion added a commit to JiaLiPassion/angular that referenced this issue Feb 2, 2018

matsko added a commit that referenced this issue Feb 14, 2018

@matsko matsko closed this in 1d571b2 Feb 14, 2018

vicb added a commit that referenced this issue Feb 22, 2018

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment