I wrote the second test case as an example where the white-listed touch action doesn't match the real touch action. In the overlap of the blue and green boxes the white-listed touch action will be pan-y but the true touch-action is auto because the green box is stacked on top.
flackr@: yes, I basically took the two test cases that you wrote :)
Could this also be one of the reasons that we get 10% mismatch comparing white-listed vs effective touch action?
Hard to say without seeing the concrete examples since we also seem to have a bug computing the white-listed touch action, but the second test case is where we expect to have a mismatch between the white listed and effective touch action with our current implementation. This can be fixed but requires a lot of overlap testing in the paint code.
While testing https://jsbin.com/yodibuy/1/edit?html,css,js,output on the master branch, I found that if you touch many times too quickly the following DCHECK fails.
content/browser/renderer_host/input/legacy_input_router_impl.cc(496) LegacyInputRouterImpl::OnSetTouchAction touch_event_queue_->IsPendingAckTouchStart().
Cc: -flackr@chromium.org xidac...@chromium.org dtapu...@chromium.org Owner: flackr@chromium.org Status: Started (was: Assigned)
I found the issue. We gather the target rects per layer, but we get the effective touch action off of the layer rather than the object the rect came from. This means that when a composited layer has a non-composited descendant with a touch-action we create an auto whitelisted region for it. We should never have touch-action: auto; whitelisted regions.
I'm working on a patch to fix this.
Comment 1 by flackr@chromium.org
, Aug 15 2017