automation_custom_bindings needs to handle blur events too.

automation_custom_bindings needs to handle blur events too.

In the automation API used by ChromeVox, focus events are
handled specially, because windows tend to fire focus events
due to local focus changes even when they don't have focus
globally - so when we get a focus event we use that as a
signal to compute which node really has focus and fire the
focus event on the proper node if needed.

However, Chrome also fires "blur" events, and when focus is
lost that's the only event that will fire, and it needs to
be handled the same way.

Leaving out "blur" led to a bug where calling
setSequentialFocusNavigationStartingPoint on a node
would cause focus to be lost (correctly), but ChromeVox
wouldn't get the notification that focus was lost
right away with eventFrom=action. So when focus was
checked later, ChromeVox would discover that focus
was suddenly on the root of the document and mistakenly
treat that as a real focus event.

When blur is handled the same way as focus in
automation_custom_bindings, ChromeVox gets the blur event
immediately in response to calling
setSequentialFocusNavigationStartingPoint, and
because eventFrom=action is set, it ignores it
(correctly), and navigation of the page is unaffected.

BUG=662441
TESTED=Manually tested all three repros from bug 662441

Committed: https://crrev.com/5e5850d17ba180e02b1e7bd6d5fb1d3bdb01972e
Cr-Commit-Position: refs/heads/master@{#430368}

[dmazzoni, 2016-11-04 16:23:20]

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

[commit-bot: I haz the power, 2016-11-04 16:23:45]

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

[dmazzoni, 2016-11-04 16:40:42]

Description was changed from

==========
Handle blur events same as focus

BUG=
==========

to

==========
automation_custom_bindings needs to handle blur events too.

In the automation API used by ChromeVox, focus events are
handled specially, because windows tend to fire focus events
due to local focus changes even when they don't have focus
globally - so when we get a focus event we use that as a
signal to compute which node really has focus and fire the
focus event on the proper node if needed.

However, Chrome also fires "blur" events, and when focus is
lost that's the only event that will fire, and it needs to
be handled the same way.

Leaving out "blur" led to a bug where calling
setSequentialFocusNavigationStartingPoint on a node
would cause focus to be lost (correctly), but ChromeVox
wouldn't get the notification that focus was lost
right away with eventFrom=action. So when focus was
checked later, ChromeVox would discover that focus
was suddenly on the root of the document and mistakenly
treat that as a real focus event.

When blur is handled the same way as focus in
automation_custom_bindings, ChromeVox gets the blur event
immediately in response to calling
setSequentialFocusNavigationStartingPoint, and
because eventFrom=action is set, it ignores it
(correctly), and navigation of the page is unaffected.

BUG=662441
TESTED=Manually tested all three repros from bug 662441
==========

[dmazzoni, 2016-11-04 16:40:42]

dmazzoni@chromium.org changed reviewers:
+ dtseng@chromium.org

[David Tseng, 2016-11-04 16:42:29]

lgtm

[commit-bot: I haz the power, 2016-11-04 17:13:15]

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

[commit-bot: I haz the power, 2016-11-04 17:13:15]

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

[dmazzoni, 2016-11-07 19:48:10]

The CQ bit was checked by dmazzoni@chromium.org

[dmazzoni, 2016-11-07 19:48:11]

The patchset sent to the CQ was uploaded after l-g-t-m from dtseng@chromium.org
Link to the patchset: https://codereview.chromium.org/2479563004/#ps20001
(title: "Only handle blur events on root")

[commit-bot: I haz the power, 2016-11-07 19:48:39]

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, 2016-11-07 20:46:31]

Description was changed from

==========
automation_custom_bindings needs to handle blur events too.

In the automation API used by ChromeVox, focus events are
handled specially, because windows tend to fire focus events
due to local focus changes even when they don't have focus
globally - so when we get a focus event we use that as a
signal to compute which node really has focus and fire the
focus event on the proper node if needed.

However, Chrome also fires "blur" events, and when focus is
lost that's the only event that will fire, and it needs to
be handled the same way.

Leaving out "blur" led to a bug where calling
setSequentialFocusNavigationStartingPoint on a node
would cause focus to be lost (correctly), but ChromeVox
wouldn't get the notification that focus was lost
right away with eventFrom=action. So when focus was
checked later, ChromeVox would discover that focus
was suddenly on the root of the document and mistakenly
treat that as a real focus event.

When blur is handled the same way as focus in
automation_custom_bindings, ChromeVox gets the blur event
immediately in response to calling
setSequentialFocusNavigationStartingPoint, and
because eventFrom=action is set, it ignores it
(correctly), and navigation of the page is unaffected.

BUG=662441
TESTED=Manually tested all three repros from bug 662441
==========

to

==========
automation_custom_bindings needs to handle blur events too.

In the automation API used by ChromeVox, focus events are
handled specially, because windows tend to fire focus events
due to local focus changes even when they don't have focus
globally - so when we get a focus event we use that as a
signal to compute which node really has focus and fire the
focus event on the proper node if needed.

However, Chrome also fires "blur" events, and when focus is
lost that's the only event that will fire, and it needs to
be handled the same way.

Leaving out "blur" led to a bug where calling
setSequentialFocusNavigationStartingPoint on a node
would cause focus to be lost (correctly), but ChromeVox
wouldn't get the notification that focus was lost
right away with eventFrom=action. So when focus was
checked later, ChromeVox would discover that focus
was suddenly on the root of the document and mistakenly
treat that as a real focus event.

When blur is handled the same way as focus in
automation_custom_bindings, ChromeVox gets the blur event
immediately in response to calling
setSequentialFocusNavigationStartingPoint, and
because eventFrom=action is set, it ignores it
(correctly), and navigation of the page is unaffected.

BUG=662441
TESTED=Manually tested all three repros from bug 662441
==========

[commit-bot: I haz the power, 2016-11-07 20:46:32]

Committed patchset #2 (id:20001)

[commit-bot: I haz the power, 2016-11-07 21:19:00]

Description was changed from

==========
automation_custom_bindings needs to handle blur events too.

In the automation API used by ChromeVox, focus events are
handled specially, because windows tend to fire focus events
due to local focus changes even when they don't have focus
globally - so when we get a focus event we use that as a
signal to compute which node really has focus and fire the
focus event on the proper node if needed.

However, Chrome also fires "blur" events, and when focus is
lost that's the only event that will fire, and it needs to
be handled the same way.

Leaving out "blur" led to a bug where calling
setSequentialFocusNavigationStartingPoint on a node
would cause focus to be lost (correctly), but ChromeVox
wouldn't get the notification that focus was lost
right away with eventFrom=action. So when focus was
checked later, ChromeVox would discover that focus
was suddenly on the root of the document and mistakenly
treat that as a real focus event.

When blur is handled the same way as focus in
automation_custom_bindings, ChromeVox gets the blur event
immediately in response to calling
setSequentialFocusNavigationStartingPoint, and
because eventFrom=action is set, it ignores it
(correctly), and navigation of the page is unaffected.

BUG=662441
TESTED=Manually tested all three repros from bug 662441
==========

to

==========
automation_custom_bindings needs to handle blur events too.

In the automation API used by ChromeVox, focus events are
handled specially, because windows tend to fire focus events
due to local focus changes even when they don't have focus
globally - so when we get a focus event we use that as a
signal to compute which node really has focus and fire the
focus event on the proper node if needed.

However, Chrome also fires "blur" events, and when focus is
lost that's the only event that will fire, and it needs to
be handled the same way.

Leaving out "blur" led to a bug where calling
setSequentialFocusNavigationStartingPoint on a node
would cause focus to be lost (correctly), but ChromeVox
wouldn't get the notification that focus was lost
right away with eventFrom=action. So when focus was
checked later, ChromeVox would discover that focus
was suddenly on the root of the document and mistakenly
treat that as a real focus event.

When blur is handled the same way as focus in
automation_custom_bindings, ChromeVox gets the blur event
immediately in response to calling
setSequentialFocusNavigationStartingPoint, and
because eventFrom=action is set, it ignores it
(correctly), and navigation of the page is unaffected.

BUG=662441
TESTED=Manually tested all three repros from bug 662441

Committed: https://crrev.com/5e5850d17ba180e02b1e7bd6d5fb1d3bdb01972e
Cr-Commit-Position: refs/heads/master@{#430368}
==========

[commit-bot: I haz the power, 2016-11-07 21:19:01]

Patchset 2 (id:??) landed as
https://crrev.com/5e5850d17ba180e02b1e7bd6d5fb1d3bdb01972e
Cr-Commit-Position: refs/heads/master@{#430368}