Do not dispatch gestures to a NULL aura::Window target

Do not dispatch gestures to a NULL aura::Window target

It is possible for the gesture recognizer to report
a NULL target for a gesture event, in which case
we should not attempt event dispatch. An early return
already exists in
WindowEventDispatcher::DispatchGestureEvent() to
guard against this possibility, so add a similar
check to WindowEventDispatcher::ProcessGestures().

BUG=384962
TEST=WindowEventDispatcherTest.CallToProcessedTouchEvent

Committed: https://src.chromium.org/viewvc/chrome?view=rev&revision=289152

[tdanderson, 2014-08-08 17:48:59]

Tim and Sadrul, what do you think? This looks like it should fix the crash as
reported in crbug.com/384962.

[tdresser, 2014-08-08 18:04:35]

On 2014/08/08 17:48:59, tdanderson wrote:
> Tim and Sadrul, what do you think? This looks like it should fix the crash as
> reported in crbug.com/384962.

Terry and I discussed this, and I'm convinced this is the right fix.
If a touch event results in a window being destroyed, then we'll return NULL
from GetGestureTarget.

[tdresser, 2014-08-08 19:36:54]

On 2014/08/08 18:04:35, tdresser wrote:
> On 2014/08/08 17:48:59, tdanderson wrote:
> > Tim and Sadrul, what do you think? This looks like it should fix the crash
as
> > reported in crbug.com/384962.
> 
> Terry and I discussed this, and I'm convinced this is the right fix.
> If a touch event results in a window being destroyed, then we'll return NULL
> from GetGestureTarget.

Ahem. LGTM.

[sadrul, 2014-08-08 19:42:05]

Can you write a test for this?

[tdanderson, 2014-08-11 20:04:33]

On 2014/08/08 19:42:05, sadrul wrote:
> Can you write a test for this?

Actually, it doesn't look like I can. Tim and I took a look at this
and it seems we'd need to invoke a code path which sets a NULL consumer
for one of the entries of 
GestureRecognizerImpl::touch_id_target_for_gestures_ , but no 
such code paths exist.

So in theory this CL is unnecessary, but the stack in the crash report 
says otherwise. Do you have any insight into this?

[tdanderson, 2014-08-12 21:19:12]

On 2014/08/11 20:04:33, tdanderson wrote:
> On 2014/08/08 19:42:05, sadrul wrote:
> > Can you write a test for this?
> 
> Actually, it doesn't look like I can. Tim and I took a look at this
> and it seems we'd need to invoke a code path which sets a NULL consumer
> for one of the entries of 
> GestureRecognizerImpl::touch_id_target_for_gestures_ , but no 
> such code paths exist.
> 
> So in theory this CL is unnecessary, but the stack in the crash report 
> says otherwise. Do you have any insight into this?

This issue was fixed as a side effect of Tim's eager GR patch
landing very recently (https://codereview.chromium.org/393953012)
which is why I was unable to write a test that failed without
my change and passed with my change. However, the test I've added
here (WindowEventDispatcherTest.CallToProcessedTouchEvent) will
fail in M37 without my change and pass in M37 with my change.

[sadrul, 2014-08-12 21:20:50]

lgtm

[tdanderson, 2014-08-12 21:21:30]

The CQ bit was checked by tdanderson@chromium.org

[commit-bot: I haz the power, 2014-08-12 21:26:26]

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

[commit-bot: I haz the power, 2014-08-13 01:41:40]

Change committed as 289152