Fix movementX/Y polyfill with capture events

[gaearon]

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 the screenX/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 its movementX/Y, and then we create another object in the bubble phase, and its movementX/Y is calculated to be 0 (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 and movementY 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:

        <div style={{
          width: '100vw',
          height: '100vh',
          background: 'red'
        }}
          onMouseDown={e => {
            if (e.movementX !== e.nativeEvent.movementX) {
              console.error('noooooo', e.movementX, e.nativeEvent.movementX)
            }
            if (e.movementY !== e.nativeEvent.movementY) {
              console.error('noooooo', e.movementY, e.nativeEvent.movementY)
            }
          }}
          onMouseDownCapture={e => {
            if (e.movementX !== e.nativeEvent.movementX) {
              console.error('noooooo', e.movementX, e.nativeEvent.movementX)
            }
            if (e.movementY !== e.nativeEvent.movementY) {
              console.error('noooooo', e.movementY, e.nativeEvent.movementY)
            }
          }}
          onMouseMove={e => {
            if (e.movementX !== e.nativeEvent.movementX) {
              console.error('noooooo', e.movementX, e.nativeEvent.movementX)
            }
            if (e.movementY !== e.nativeEvent.movementY) {
              console.error('noooooo', e.movementY, e.nativeEvent.movementY)
            }
          }}
          onMouseMoveCapture={e => {
            if (e.movementX !== e.nativeEvent.movementX) {
              console.error('noooooo', e.movementX, e.nativeEvent.movementX)
            }
            if (e.movementY !== e.nativeEvent.movementY) {
              console.error('noooooo', e.movementY, e.nativeEvent.movementY)
            }
          }}
          onMouseUp={e => {
            if (e.movementX !== e.nativeEvent.movementX) {
              console.error('noooooo', e.movementX, e.nativeEvent.movementX)
            }
            if (e.movementY !== e.nativeEvent.movementY) {
              console.error('noooooo', e.movementY, e.nativeEvent.movementY)
            }
          }}
          onMouseUpCapture={e => {
            if (e.movementX !== e.nativeEvent.movementX) {
              console.error('noooooo', e.movementX, e.nativeEvent.movementX)
            }
            if (e.movementY !== e.nativeEvent.movementY) {
              console.error('noooooo', e.movementY, e.nativeEvent.movementY)
            }
          }}
        />,

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).

[codesandbox-ci]

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:

Sandbox	Source
React	Configuration

[sizebot]

No significant bundle size changes to report.

Size changes (experimental)

Generated by 🚫 dangerJS against f976c48

[sizebot]

No significant bundle size changes to report.

Size changes (stable)

Generated by 🚫 dangerJS against f976c48

[IDisposable]

Won't this GC root the event? This seems like a leak.

[gaearon]

It will root only one (the very last) mouse event, and only on IE11, so this should not be an issue.