-
Notifications
You must be signed in to change notification settings - Fork 46.9k
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
Fix movementX/Y polyfill with capture events #19672
Conversation
This pull request is automatically built and testable in CodeSandbox. To see build info of the built libraries, click here or the icon next to each commit SHA. Latest deployment of this branch, based on commit f976c48:
|
lastMovementX = 0; | ||
lastMovementY = 0; | ||
} | ||
lastMouseEvent = event; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Won't this GC root the event? This seems like a leak.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It will root only one (the very last) mouse event, and only on IE11, so this should not be an issue.
* Fix movementX/Y polyfill with capture events * Remove unnecesary call for better inlining
This is a blocker I need to resolve for #19648.
Our
movementX/Y
polyfill is currently broken with the modern event system if you use a capture event. This is because it diffs thescreenX/Y
with the last event's values, but now we have two synthetic events per one native event (due to capture and bubble phase). So we create an event in the capture phase, set itsmovementX/Y
, and then we create another object in the bubble phase, and itsmovementX/Y
is calculated to be0
(because it is diffed with the event we just created earlier).To fix this, I am pulling this logic out in one place and update both
movementX
andmovementY
values together and only if the native event has changed. This means we retain one last mouse event at a time (when the polyfill is used, which is IE11-only). Seems ok.Test Plan
Added a test that previously failed.
I also manually tested by forcing the polyfill to always be used and running it with this fixture:
Clicking and moving works as expected (no violations). There is a calculation bug every time after we move cursor outside the screen and bring it back, but this bug existed in 16 too, and I don't think it's worth fixing. (We'll remove the polyfill eventually anyway).