-
Notifications
You must be signed in to change notification settings - Fork 24.4k
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
W3CPointerEvents: properly update hit path during native gestures #37638
Conversation
This pull request was exported from Phabricator. Differential Revision: D46226021 |
Base commit: 3f0caed |
This pull request was exported from Phabricator. Differential Revision: D46226021 |
…cebook#37638) Summary: Pull Request resolved: facebook#37638 Changelog: [Android] [Fixed] - W3CPointerEvents: properly update hit path during native gestures Per [the W3C spec](https://www.w3.org/TR/pointerevents/#the-pointercancel-event), we need to fire pointerout and pointerleave after firing a pointercancel. However, in cases where the pointer doesn't physically leave the target after a cancel (e.g. scrolling by clicking and dragging), we would never re-fire a pointerenter event once the native gesture was completed. This change fixes the bug by clearing out the last hit path (and other relevant state) for the pointer when we start handling a native gesture. Then we'll re-fire a pointerenter as expected upon the next motion event (due to the logic in handleHitStateDivergence). Note: this bug only affected hovering pointers (e.g. mouse) because for non-hovering pointers the native gesture won't end unless the pointer is physically removed (i.e. finger is lifted). Reviewed By: javache Differential Revision: D46226021 fbshipit-source-id: 66d53aa885a4c3029aeb6d74c8556863dac9b635
…cebook#37638) Summary: Pull Request resolved: facebook#37638 Changelog: [Android] [Fixed] - W3CPointerEvents: properly update hit path during native gestures Per [the W3C spec](https://www.w3.org/TR/pointerevents/#the-pointercancel-event), we need to fire pointerout and pointerleave after firing a pointercancel. However, in cases where the pointer doesn't physically leave the target after a cancel (e.g. scrolling by clicking and dragging), we would never re-fire a pointerenter event once the native gesture was completed. This change fixes the bug by clearing out the last hit path (and other relevant state) for the pointer when we start handling a native gesture. Then we'll re-fire a pointerenter as expected upon the next motion event (due to the logic in handleHitStateDivergence). Note: this bug only affected hovering pointers (e.g. mouse) because for non-hovering pointers the native gesture won't end unless the pointer is physically removed (i.e. finger is lifted). Reviewed By: javache Differential Revision: D46226021 fbshipit-source-id: c583771b99efd1480b51e44bb0bf0a9f3a97779b
This pull request was exported from Phabricator. Differential Revision: D46226021 |
…cebook#37638) Summary: Pull Request resolved: facebook#37638 Changelog: [Android] [Fixed] - W3CPointerEvents: properly update hit path during native gestures Per [the W3C spec](https://www.w3.org/TR/pointerevents/#the-pointercancel-event), we need to fire pointerout and pointerleave after firing a pointercancel. However, in cases where the pointer doesn't physically leave the target after a cancel (e.g. scrolling by clicking and dragging), we would never re-fire a pointerenter event once the native gesture was completed. This change fixes the bug by clearing out the last hit path (and other relevant state) for the pointer when we start handling a native gesture. Then we'll re-fire a pointerenter as expected upon the next motion event (due to the logic in handleHitStateDivergence). Note: this bug only affected hovering pointers (e.g. mouse) because for non-hovering pointers the native gesture won't end unless the pointer is physically removed (i.e. finger is lifted). Reviewed By: javache Differential Revision: D46226021 fbshipit-source-id: b5dbd2982f72c877a6f0cdbb91c8549bdc739050
This pull request was exported from Phabricator. Differential Revision: D46226021 |
1 similar comment
This pull request was exported from Phabricator. Differential Revision: D46226021 |
…cebook#37638) Summary: Pull Request resolved: facebook#37638 Changelog: [Android] [Fixed] - W3CPointerEvents: properly update hit path during native gestures Per [the W3C spec](https://www.w3.org/TR/pointerevents/#the-pointercancel-event), we need to fire pointerout and pointerleave after firing a pointercancel. However, in cases where the pointer doesn't physically leave the target after a cancel (e.g. scrolling by clicking and dragging), we would never re-fire a pointerenter event once the native gesture was completed. This change fixes the bug by clearing out the last hit path (and other relevant state) for the pointer when we start handling a native gesture. Then we'll re-fire a pointerenter as expected upon the next motion event (due to the logic in handleHitStateDivergence). Note: this bug only affected hovering pointers (e.g. mouse) because for non-hovering pointers the native gesture won't end unless the pointer is physically removed (i.e. finger is lifted). Reviewed By: javache Differential Revision: D46226021 fbshipit-source-id: 585ebb806d2e1417f8f6fb462b85b3ddf4ae2b41
…cebook#37638) Summary: Pull Request resolved: facebook#37638 Changelog: [Android] [Fixed] - W3CPointerEvents: properly update hit path during native gestures Per [the W3C spec](https://www.w3.org/TR/pointerevents/#the-pointercancel-event), we need to fire pointerout and pointerleave after firing a pointercancel. However, in cases where the pointer doesn't physically leave the target after a cancel (e.g. scrolling by clicking and dragging), we would never re-fire a pointerenter event once the native gesture was completed. This change fixes the bug by clearing out the last hit path (and other relevant state) for the pointer when we start handling a native gesture. Then we'll re-fire a pointerenter as expected upon the next motion event (due to the logic in handleHitStateDivergence). Note: this bug only affected hovering pointers (e.g. mouse) because for non-hovering pointers the native gesture won't end unless the pointer is physically removed (i.e. finger is lifted). Reviewed By: javache Differential Revision: D46226021 fbshipit-source-id: fb417bdab14167fe6f3020ff269aa80f6a3fffb9
This pull request was exported from Phabricator. Differential Revision: D46226021 |
…cebook#37638) Summary: Pull Request resolved: facebook#37638 Changelog: [Android] [Fixed] - W3CPointerEvents: properly update hit path during native gestures Per [the W3C spec](https://www.w3.org/TR/pointerevents/#the-pointercancel-event), we need to fire pointerout and pointerleave after firing a pointercancel. However, in cases where the pointer doesn't physically leave the target after a cancel (e.g. scrolling by clicking and dragging), we would never re-fire a pointerenter event once the native gesture was completed. This change fixes the bug by clearing out the last hit path (and other relevant state) for the pointer when we start handling a native gesture. Then we'll re-fire a pointerenter as expected upon the next motion event (due to the logic in handleHitStateDivergence). Note: this bug only affected hovering pointers (e.g. mouse) because for non-hovering pointers the native gesture won't end unless the pointer is physically removed (i.e. finger is lifted). Reviewed By: javache Differential Revision: D46226021 fbshipit-source-id: 1267b6e122dfd4aafd47028d87c9be7e95d7a001
This pull request was exported from Phabricator. Differential Revision: D46226021 |
This pull request has been merged in 396cdac. |
Summary:
Changelog: [Android] [Fixed] - W3CPointerEvents: properly update hit path during native gestures
Per the W3C spec, we need to fire pointerout and pointerleave after firing a pointercancel. However, in cases where the pointer doesn't physically leave the target after a cancel (e.g. scrolling by clicking and dragging), we would never re-fire a pointerenter event once the native gesture was completed. This change fixes the bug by clearing out the last hit path (and other relevant state) for the pointer when we start handling a native gesture. Then we'll re-fire a pointerenter as expected upon the next motion event (due to the logic in handleHitStateDivergence).
Note: this bug only affected hovering pointers (e.g. mouse) because for non-hovering pointers the native gesture won't end unless the pointer is physically removed (i.e. finger is lifted).
Reviewed By: javache
Differential Revision: D46226021