Relax touch hit testing in CC to look at all layers under a point

Relax touch hit testing in CC to look at all layers under a point

CC touch hit testing now (as of http://crrev.com/264395 does a ray cast
through all layers under the touched point.  We included an optimization
to stop searching once you reach a layer we know is opaque to hit testing.
This breaks the common case of sites with a touch handler on the document
because blink has an optimization to effectively disable touch hit testing
in that scenario (since there's no benefit to be had to expensive rect
computation) by marking just the entire root layer with a handler region.

This change removes this opaque-to-hit-testing optimization.  There's some
risk that we'll block on main more often, but it should be rare (you'd
need a scrolling layer without a handler over top of a layer with a
handler).

This also fixes the case where a layer has a region that is supposed to
be transparent to hit-testing with the CSS pointer-events: none property.

BUG=366034, 269598
Committed: https://src.chromium.org/viewvc/chrome?view=rev&revision=266402

[Rick Byers, 2014-04-24 19:23:43]

Ian, PTAL

[enne (OOO), 2014-04-24 19:32:11]

Can you add a unit test for the case that was broken?

[Rick Byers, 2014-04-24 21:07:54]

On 2014/04/24 19:32:11, enne wrote:
> Can you add a unit test for the case that was broken?

Yeah I initially did that, but it seemed a little silly to verify that we're NOT
special-casing opaque layers (eg. why opaque layers when there's no code here
treating them special?  Why not some other random property of a layer that we
could in theory choose to special case?).  Anyway I guess special-casing opaque
layers is a pretty natural thing to want to do, so it certainly doesn't hurt to
test that we're NOT doing that anymore.  PTAL.

[Ian Vollick, 2014-04-25 16:07:42]

On 2014/04/24 21:07:54, Rick Byers wrote:
> On 2014/04/24 19:32:11, enne wrote:
> > Can you add a unit test for the case that was broken?
> 
> Yeah I initially did that, but it seemed a little silly to verify that we're
NOT
> special-casing opaque layers (eg. why opaque layers when there's no code here
> treating them special?  Why not some other random property of a layer that we
> could in theory choose to special case?).  Anyway I guess special-casing
opaque
> layers is a pretty natural thing to want to do, so it certainly doesn't hurt
to
> test that we're NOT doing that anymore.  PTAL.

lgtm.

[Ian Vollick, 2014-04-25 16:07:44]

The CQ bit was checked by vollick@chromium.org

[commit-bot: I haz the power, 2014-04-25 22:16:11]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/rbyers@chromium.org/250663003/20001

[commit-bot: I haz the power, 2014-04-25 23:57:38]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2014-04-25 23:57:38]

Try jobs failed on following builders:
  tryserver.chromium on win_chromium_rel

[Rick Byers, 2014-04-26 00:39:57]

The CQ bit was checked by rbyers@chromium.org

[commit-bot: I haz the power, 2014-04-26 00:45:24]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/rbyers@chromium.org/250663003/20001

[commit-bot: I haz the power, 2014-04-26 04:32:32]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2014-04-26 04:32:33]

Try jobs failed on following builders:
  tryserver.chromium on win_chromium_x64_rel

[Ian Vollick, 2014-04-26 09:56:28]

The CQ bit was checked by vollick@chromium.org

[commit-bot: I haz the power, 2014-04-26 09:58:10]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/rbyers@chromium.org/250663003/20001

[commit-bot: I haz the power, 2014-04-27 00:27:38]

Change committed as 266402