Do not send mouse-move when target is destroyed due to synthesized mouse-exit in RootWindow

Do not send mouse-move when target is destroyed due to synthesized mouse-exit in RootWindow

When a RootWindow is going to dispatch a mouse-move to a child, if the
target is different than the current mouse_moved_handler_, it sends a
synthesized mouse-exit to to mouse_moved_handler_. The target might be
destroyed because of this mouse-exit. If that's the case, the original
mouse-move should not be sent to the destroyed target.

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

[mohsen, 2013-10-08 15:29:15]

Please take a look...

[sky, 2013-10-08 15:55:48]

You need a test case for this.

[mohsen, 2013-10-08 23:20:39]

Unit test added.

[sky, 2013-10-09 13:12:43]

https://codereview.chromium.org/26499003/diff/11001/ui/aura/root_window_unitt...
File ui/aura/root_window_unittest.cc (right):

https://codereview.chromium.org/26499003/diff/11001/ui/aura/root_window_unitt...
ui/aura/root_window_unittest.cc:1080: OnMouseExitDeletingEventFilter* w1_filter
=
Does this leak?

[sky, 2013-10-09 13:12:52]

And thanks for the test!

[mohsen, 2013-10-09 15:12:30]

https://codereview.chromium.org/26499003/diff/11001/ui/aura/root_window_unitt...
File ui/aura/root_window_unittest.cc (right):

https://codereview.chromium.org/26499003/diff/11001/ui/aura/root_window_unitt...
ui/aura/root_window_unittest.cc:1080: OnMouseExitDeletingEventFilter* w1_filter
=
On 2013/10/09 13:12:44, sky wrote:
> Does this leak?

SetEventFilter will pass the ownership of event filter to the window. Actually,
I wanted to add a note for it, but I forgot. Added now.

[sky, 2013-10-09 16:28:38]

LGTM

[commit-bot: I haz the power, 2013-10-09 17:06:04]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/mohsen@chromium.org/26499003/24001

[commit-bot: I haz the power, 2013-10-09 23:47:51]

Change committed as 227835