onValueChange not triggered on input based elements for touch events #932
Comments
|
I can't reproduce this in the RNW storybook. Switch and onValueChange work as expected in Chrome on my mobile device and when emulating touch events in desktop Chrome on macOS. |
|
Seems to be cause by other plugin messing up with events. Will update if I find the real cause. Closing for now. |
|
Sorry for false report. |
|
I've found conflicting library. It's nativebase. Inputs doesn't trigger Create repo, which demonstrates the issue https://github.com/mauron85/rn-switch-glitch |
|
Reported issue GeekyAnts/NativeBase#1874 |
|
@necolas I did some additional research and it might be issue with react-native-web after all. The problem seems to occur when Example: This only works with mouse events. Touch event is not propagated correctly. Interestly wrapping touchable in another touchable works: I've created example you can reproduce this issue: https://grateful-stem.glitch.me/ |
|
Reverting createElement to https://raw.githubusercontent.com/mauron85/react-native-web/extended/src/modules/createElement/index.js fixes the problem. So it really seems to be related to this commit 893963a EDIT: But it's not as easy as just reverting, because then touchables will be called twice. |
Browsers dispatch mouse events after touch events: https://developer.mozilla.org/en-US/docs/Web/API/Touch_events/Supporting_both_TouchEvent_and_MouseEvent There have been several attempts to avoid this behaviour affecting the ResponderEvent system. The previous approach of cancelling the event in the `onResponderRelease` event handler can end up cancelling other events that are expected, e.g., `focus`. Instead, this patch changes the `ResponderEventPlugin.extractEvents` function to filter the mouse events that occur a short time after a touch event. (It's assumed that people will not be clicking a mouse within a few hundred ms of performing a touch.) This allows the ResponderEvent system to function as expected and leaves other callbacks to fire as they would be expected to in React DOM, i.e., both 'onTouchStart' and 'onMouseDown' will be called following a touch start. Fix #932 Ref #802
|
Hi @necolas. After reading commit comment and previous issues, this seems like kind of hard to solve problem. It's easy to break something else. Anyway I've just tried mouse-event-filter branch and it's seems like it fixes this particular issue. |
Browsers dispatch mouse events after touch events: https://developer.mozilla.org/en-US/docs/Web/API/Touch_events/Supporting_both_TouchEvent_and_MouseEvent There have been several attempts to avoid this behaviour affecting the ResponderEvent system. The previous approach of cancelling the event in the `onResponderRelease` event handler can end up cancelling other events that are expected, e.g., `focus`. Instead, this patch changes the `ResponderEventPlugin.extractEvents` function to filter the mouse events that occur a short time after a touch event. (It's assumed that people will not be clicking a mouse within a few hundred ms of performing a touch.) This allows the ResponderEvent system to function as expected and leaves other callbacks to fire as they would be expected to in React DOM, i.e., both `onTouchStart` and `onMouseDown` will be called following a touch start. Fix #932 Close #938 Ref #802
Browsers dispatch mouse events after touch events: https://developer.mozilla.org/en-US/docs/Web/API/Touch_events/Supporting_both_TouchEvent_and_MouseEvent There have been several attempts to avoid this behaviour affecting the ResponderEvent system. The previous approach of cancelling the event in the `onResponderRelease` event handler can end up cancelling other events that are expected, e.g., `focus`. Instead, this patch changes the `ResponderEventPlugin.extractEvents` function to filter the mouse events that occur a short time after a touch event. (It's assumed that people will not be clicking a mouse within a few hundred ms of performing a touch.) This allows the ResponderEvent system to function as expected and leaves other callbacks to fire as they would be expected to in React DOM, i.e., both `onTouchStart` and `onMouseDown` will be called following a touch start. Fix #835 Fix #888 Fix #932 Close #938 Ref #802
Browsers dispatch mouse events after touch events: https://developer.mozilla.org/en-US/docs/Web/API/Touch_events/Supporting_both_TouchEvent_and_MouseEvent There have been several attempts to avoid this behaviour affecting the ResponderEvent system. The previous approach of cancelling the event in the `onResponderRelease` event handler can end up cancelling other events that are expected, e.g., `focus`. Instead, this patch changes the `ResponderEventPlugin.extractEvents` function to filter the mouse events that occur a short time after a touch event. (It's assumed that people will not be clicking a mouse within a few hundred ms of performing a touch.) This allows the ResponderEvent system to function as expected and leaves other callbacks to fire as they would be expected to in React DOM, i.e., both `onTouchStart` and `onMouseDown` will be called following a touch start. Fix necolas#835 Fix necolas#888 Fix necolas#932 Close necolas#938 Ref necolas#802
Do you want to request a feature or report a bug?
bug
What is the current behavior?
Elements like Switch, Input... doesn't fire
onValueChangeon mobile browsers and Chrome when switched to emulate touch events.**If the current behavior is a bug, please provide the steps to reproduce and
Not sure if this is needed but issue can be easily reproduced on simple Switch component.
Switch
onValueChangeon mobile browsers and Chrome is not called.How to reproduce:
What is the expected behavior?
Switch
onValueChangewill be calledEnvironment (include versions). Did this work in previous versions?
Yes it did. Not sure about exact version number, but version used following createElement works.
I think problem is related to line: https://github.com/necolas/react-native-web/blob/master/packages/react-native-web/src/exports/createElement/index.js#L56
The text was updated successfully, but these errors were encountered: