It looks like this pull request may not have tests. Please make sure to add tests before merging. If you need an exemption to this rule, contact Hixie on the #hackers channel in Chat (don't just cc him here, he won't see it! He's on Discord!).

If you are not sure if you need tests, consider this rule of thumb: the purpose of a test is to make sure someone doesn't accidentally revert the fix. Ask yourself, is there anything in your PR that you feel it is important we not accidentally revert back to how it was before your fix?

Reviewers: Read the Tree Hygiene page and make sure this patch meets those guidelines before LGTMing.

@dnfield Hey Dan! I added a test that pretty much checks that the value can be set. Is that alright?

Also cc @jiahaog

Going to revert this - @goderbauer says hes' going to add some valid concerns we discussed offline.

I would have expected that customers would create their own binding subclass here with a feature like that and use those in the test (at least as a one-off until we implement a proper solution for this).

The change as it stands is currently making it too easy to leak state between tests. It is also missing proper documentation around what it means to change this property. The whole API seems easy to miss-use as designed.

Furthermore, to fully fix the original problem we should think about what we can do to properly recognize pointer events coming from adb to have those actually drive the test instead of hacking into the pointer event handling of the test framework.