Candidate fix for PointerEvent-OOPIF combination not working.

Candidate fix for PointerEvent-OOPIF combination not working.

Prior to enabling PointerEvents, OOPIFs with TouchEvent handlers worked.
But with PointerEvents turned on, they fail. This happens because the
InputRouterImpl sending the touch events to the OOPIF never gets
notified of the current TouchAction, in turn because ChromeClientImpl
sends the TouchAction notification via RenderView and not the
RenderWidget serving the OOPIF.

Prior to PointerEvents this was not an issue, as the touch events
would continue to flow regardlesss. But with PointerEvents, touch
events are blocked after a TouchScrollStart is issued.

This CL plumbs a LocalFrame* parameter into ChromeClient::setTouchAction
so the notification can be sent via the correct channel.

BUG=680158
Review-Url: https://codereview.chromium.org/2626133002
Cr-Commit-Position: refs/heads/master@{#443302}
Committed: https://chromium.googlesource.com/chromium/src/+/8c15a423974bf654c237bc27a2ac12cca22cccd2

[wjmaclean, 2017-01-11 20:46:07]

The CQ bit was checked by wjmaclean@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2017-01-11 20:46:49]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[wjmaclean, 2017-01-11 21:07:42]

Description was changed from

==========
Candidate fix for PointerEvent-OOPIF combination not working.

Prior to enabling PointerEvents, OOPIFs with TouchEvent handlers worked.
But with PointerEvents turned on, they fail. This happens because the
InputRouterImpl sending the touch events to the OOPIF never gets
notified of the current TouchAction, in turn because ChromeClientImpl
sends the TouchAction notification via RenderView and not the
RenderWidget serving the OOPIF.

This CL plumbs a LocalFrame* parameter into ChromeClient::setTouchAction
so the notification can be sent via the correct channel.

BUG=680158
==========

to

==========
Candidate fix for PointerEvent-OOPIF combination not working.

Prior to enabling PointerEvents, OOPIFs with TouchEvent handlers worked.
But with PointerEvents turned on, they fail. This happens because the
InputRouterImpl sending the touch events to the OOPIF never gets
notified of the current TouchAction, in turn because ChromeClientImpl
sends the TouchAction notification via RenderView and not the
RenderWidget serving the OOPIF.

Prior to PointerEvents this was not an issue, as the touch events
would continue to flow regardlesss. But with PointerEvents, touch
events are blocked after a TouchScrollStart is issued.

This CL plumbs a LocalFrame* parameter into ChromeClient::setTouchAction
so the notification can be sent via the correct channel.

BUG=680158
==========

[commit-bot: I haz the power, 2017-01-11 22:04:42]

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

[commit-bot: I haz the power, 2017-01-11 22:04:43]

Dry run: Try jobs failed on following builders:
  linux_chromium_rel_ng on master.tryserver.chromium.linux (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.linux/builders/linux_chromium_...)

[wjmaclean, 2017-01-12 13:21:04]

The CQ bit was checked by wjmaclean@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2017-01-12 13:21:17]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2017-01-12 15:05:22]

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

[commit-bot: I haz the power, 2017-01-12 15:05:23]

Dry run: This issue passed the CQ dry run.

[wjmaclean, 2017-01-12 15:11:14]

wjmaclean@chromium.org changed reviewers:
+ bokan@chromium.org

[wjmaclean, 2017-01-12 15:12:12]

bokan@ - This changes the plumbing for calls to setTouchAction() so that touch
events for OOPIF will work properly. Could you please take a look?

[dtapuska, 2017-01-12 16:17:51]

On 2017/01/12 15:12:12, wjmaclean wrote:
> bokan@ - This changes the plumbing for calls to setTouchAction() so that touch
> events for OOPIF will work properly. Could you please take a look?

drive by lgtm

[bokan, 2017-01-12 16:41:40]

Logic looks fine. Could we get a test for touch-action in an OOPIF? lgtm to land
this since I understand there's time pressure, but I'd like to see a followup
add a test.

[wjmaclean, 2017-01-12 16:45:14]

On 2017/01/12 16:41:40, bokan wrote:
> Logic looks fine. Could we get a test for touch-action in an OOPIF? lgtm to
land
> this since I understand there's time pressure, but I'd like to see a followup
> add a test.

Yes, I've been thinking about how to do a meaningful OOPIF test ... that may be
based around a browser test that verifies that the InputEventRouter for an oopif
gets the correct TouchAction, or at least that an extended touch sequence
doesn't start creating GestureScroll events.

I'll land this now, and continue working on the test.

[wjmaclean, 2017-01-12 16:45:20]

The CQ bit was checked by wjmaclean@chromium.org

[commit-bot: I haz the power, 2017-01-12 16:45:46]

CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2017-01-12 18:45:34]

CQ is committing da patch.

Bot data: {"patchset_id": 40001, "attempt_start_ts": 1484239520309230,
"parent_rev": "ac40ecf4ebcc9682460cdeb693c482efb1d45e55", "commit_rev":
"8c15a423974bf654c237bc27a2ac12cca22cccd2"}

[commit-bot: I haz the power, 2017-01-12 18:46:02]

Description was changed from

==========
Candidate fix for PointerEvent-OOPIF combination not working.

Prior to enabling PointerEvents, OOPIFs with TouchEvent handlers worked.
But with PointerEvents turned on, they fail. This happens because the
InputRouterImpl sending the touch events to the OOPIF never gets
notified of the current TouchAction, in turn because ChromeClientImpl
sends the TouchAction notification via RenderView and not the
RenderWidget serving the OOPIF.

Prior to PointerEvents this was not an issue, as the touch events
would continue to flow regardlesss. But with PointerEvents, touch
events are blocked after a TouchScrollStart is issued.

This CL plumbs a LocalFrame* parameter into ChromeClient::setTouchAction
so the notification can be sent via the correct channel.

BUG=680158
==========

to

==========
Candidate fix for PointerEvent-OOPIF combination not working.

Prior to enabling PointerEvents, OOPIFs with TouchEvent handlers worked.
But with PointerEvents turned on, they fail. This happens because the
InputRouterImpl sending the touch events to the OOPIF never gets
notified of the current TouchAction, in turn because ChromeClientImpl
sends the TouchAction notification via RenderView and not the
RenderWidget serving the OOPIF.

Prior to PointerEvents this was not an issue, as the touch events
would continue to flow regardlesss. But with PointerEvents, touch
events are blocked after a TouchScrollStart is issued.

This CL plumbs a LocalFrame* parameter into ChromeClient::setTouchAction
so the notification can be sent via the correct channel.

BUG=680158

Review-Url: https://codereview.chromium.org/2626133002
Cr-Commit-Position: refs/heads/master@{#443302}
Committed:
https://chromium.googlesource.com/chromium/src/+/8c15a423974bf654c237bc27a2ac...
==========

[commit-bot: I haz the power, 2017-01-12 18:46:03]

Committed patchset #3 (id:40001) as
https://chromium.googlesource.com/chromium/src/+/8c15a423974bf654c237bc27a2ac...

[Charlie Reis, 2017-01-12 19:46:00]

Description was changed from

==========
Candidate fix for PointerEvent-OOPIF combination not working.

Prior to enabling PointerEvents, OOPIFs with TouchEvent handlers worked.
But with PointerEvents turned on, they fail. This happens because the
InputRouterImpl sending the touch events to the OOPIF never gets
notified of the current TouchAction, in turn because ChromeClientImpl
sends the TouchAction notification via RenderView and not the
RenderWidget serving the OOPIF.

Prior to PointerEvents this was not an issue, as the touch events
would continue to flow regardlesss. But with PointerEvents, touch
events are blocked after a TouchScrollStart is issued.

This CL plumbs a LocalFrame* parameter into ChromeClient::setTouchAction
so the notification can be sent via the correct channel.

BUG=680158

Review-Url: https://codereview.chromium.org/2626133002
Cr-Commit-Position: refs/heads/master@{#443302}
Committed:
https://chromium.googlesource.com/chromium/src/+/8c15a423974bf654c237bc27a2ac...
==========

to

==========
Candidate fix for PointerEvent-OOPIF combination not working.

Prior to enabling PointerEvents, OOPIFs with TouchEvent handlers worked.
But with PointerEvents turned on, they fail. This happens because the
InputRouterImpl sending the touch events to the OOPIF never gets
notified of the current TouchAction, in turn because ChromeClientImpl
sends the TouchAction notification via RenderView and not the
RenderWidget serving the OOPIF.

Prior to PointerEvents this was not an issue, as the touch events
would continue to flow regardlesss. But with PointerEvents, touch
events are blocked after a TouchScrollStart is issued.

This CL plumbs a LocalFrame* parameter into ChromeClient::setTouchAction
so the notification can be sent via the correct channel.

BUG=680158

Review-Url: https://codereview.chromium.org/2626133002
Cr-Commit-Position: refs/heads/master@{#443302}
Committed:
https://chromium.googlesource.com/chromium/src/+/8c15a423974bf654c237bc27a2ac...
==========