The swipe gesture of a SwipeableDrawer component should not propagate to components located behind it.

https://codesandbox.io/s/l4r1q4p64m
I'm displaying a fixed map, using leaflet. Touch events are processed directly by leaflet, as scroll in body is disabled.
| Tech | Version |
|--------------|---------|
| Material-UI | 1.0.0-beta.39 |
| React | 16.2.0 |
| browser | Chrome 65 |
I was going to fix it, but then I saw that actually, the drawer does not propagate the events to underlying components, but it handles the _same_ event as your map, i.e. the touchstart event from the body.
I don't know how to prevent other components from handling this event; calling stopPropagation won't help here. :thinking:
I also tried to call event.stopPropagation from here, with no effect.
I don't think it's specific to the map, as the issue remains with the provided codesandbox where the event is propagated to the root div.
The event is not propagated _to_ the root div. It _comes_ from body and then goes down to the drawer, _through_ the root div. :confused: That's why I was unable to fix this "bug".
To fix this, we would have to add an invisible div container to the edge of the screen that actually catches the touch event instead of listening to the body's events.
You're right. I was thinking using capture for addEventListener would prevent this behavior, but it simply doesn't work.
To fix this, we would have to add an invisible div container to the edge of the screen that actually catches the touch event instead of listening to the body's events.
We don't need to add an extra div. We could just add an extra transparent padding to the right (or the opposite opening direction) of the drawer, and handle events directly from it.
From what I understand of the issue, both the map and the SwipeableView components handle the touch start event.
I fear there is no silver bullet solution to this problem. I would propose the following solution on userland:
.discoverability-area {
position: absolute;
top: 0;
left: 0;
bottom: 0;
width: 20px;
}
Add a transparent div with a matching the discoverability area of the SwipeableDrawer.
@oliviertassinari That solution could as well be implemented in library land. :+1: It would make the discovery-detection easier and it wouldn't bloat the component much.
@oliviertassinari Why was this closed as wontfix?
I'm currently facing this issue too, when using a swipeable drawer and a react-swipeable-view at the same time. It's really annoying and should be fixed as described above. I'll start working on that. :hourglass_flowing_sand:
The extra-div/padding solution is almost how Android does it.
Why was this closed as wontfix?
@leMaik Because it can be simply fixed on userland with a blocking div. But I guess you are right. We can move the logic into the core 馃憤