Set pointer capture on pointerdown on picker input

[NavidZ]

Chrome 73 starts sending click even to the common ancestor of down and up events even when one was inside the input element and the other one was outside. This caused this library to fail in the following scenario: User presses down on the picker input which causes the date picker and overlay to be shown. When user releases the button the overlay gets the up event and the common ancestor of these elements will get the click. Since there is a click handler on the document to close the popup, the calendar popup immediately closes.

Using pointercapture API to capture the rest of the pointerevents stream to the picker input it ensures the click event target is the picker input and that ensures the click handler doesn't dismiss the popup.

[NavidZ]

@colinhowe FYI as he was the author of the original CL.

This CL addresses #1165 in a more spec compliant way.

@DanielRuf I fixed the test here. The slow test assumed that the click goes to a parent node. But with the pointercapture API it guarantees that it is not the case.

Just as a note I believe this is a more web standard compliant way of what this library tries to achieve. The previous patch was again relying on an unspecified behavior of UAs and hence was at the mercy of the user agent on how to send the click events when user presses middle button while left button is depressed.

If you still believe this is not a proper behavior for this library feel free to close this again. I just sent this PL since you asked me to send one that addresses the comments I had here.

[colinhowe]

Thanks for pinging this to me. I was not aware of the pointer capture API!

Regardless of whether this is a regression or not in Chrome - this is a nicer change-set than the one I pulled together.

I'm still on the fence as to whether the change in Chrome is a regression or not. I'd say that the spec itself is slightly ambiguous about what the behaviour in these scenarios should be.