Merge to M51: Prevent child frames from sending bad accessibility events.

Merge to M51: Prevent child frames from sending bad accessibility events.

A recent change in M51 to have a separate accessibility tree for
each frame resulted in a subtle regression, where the
BrowserAccessibilityManager for a child frame would send
accessibility events before it was fully connected to its parent
frame. Because of how accessibility events work on Windows, when
an external accessibility client tried to respond to those events
the target node wouldn't be found when calling get_accChild to
retrieve it.

The user-visible manifestation was that NVDA spoke "unknown" a lot,
in response to those bogus events.

The fundamental idea behind the fixes is that a native accessibility
event shouldn't be fired unless the target node is a direct descendant
of the HWND for that tab. This logic needs to handle all of the cases
that arise when we have a separate BrowserAccessibilityManager for
each frame. The specific issues were:

* BrowserAccessibilityManager::GetRootManager was walking up to a parent
  frame without checking that the parent frame linked back to itself.
* MaybeCallNotifyWinEvent was checking its own delegate's HWND rather
  than the target node's delegate's HWND.
* RenderFrameHostImpl::AccessibilityGetAcceleratedWidget should only
  return a valid HWND for the main frame's current frame host.

BUG=600145
CQ_INCLUDE_TRYBOTS=tryserver.chromium.linux:linux_site_isolation

Review URL: https://codereview.chromium.org/1892593003

Cr-Commit-Position: refs/heads/master@{#387681}
(cherry picked from commit fadccf76e38b76a0eb66f750ee668e89754596b7)

Committed: https://chromium.googlesource.com/chromium/src/+/90106718b712cb8c4462c2f39bae0e53a05a263b

[dmazzoni, 2016-04-18 18:22:22]

Description was changed from

==========
Merge to M51: Prevent child frames from sending bad accessibility events.

A recent change in M51 to have a separate accessibility tree for
each frame resulted in a subtle regression, where the
BrowserAccessibilityManager for a child frame would send
accessibility events before it was fully connected to its parent
frame. Because of how accessibility events work on Windows, when
an external accessibility client tried to respond to those events
the target node wouldn't be found when calling get_accChild to
retrieve it.

The user-visible manifestation was that NVDA spoke "unknown" a lot,
in response to those bogus events.

The fundamental idea behind the fixes is that a native accessibility
event shouldn't be fired unless the target node is a direct descendant
of the HWND for that tab. This logic needs to handle all of the cases
that arise when we have a separate BrowserAccessibilityManager for
each frame. The specific issues were:

* BrowserAccessibilityManager::GetRootManager was walking up to a parent
  frame without checking that the parent frame linked back to itself.
* MaybeCallNotifyWinEvent was checking its own delegate's HWND rather
  than the target node's delegate's HWND.
* RenderFrameHostImpl::AccessibilityGetAcceleratedWidget should only
  return a valid HWND for the main frame's current frame host.

BUG=600145
CQ_INCLUDE_TRYBOTS=tryserver.chromium.linux:linux_site_isolation

Review URL: https://codereview.chromium.org/1892593003

Cr-Commit-Position: refs/heads/master@{#387681}
(cherry picked from commit fadccf76e38b76a0eb66f750ee668e89754596b7)
==========

to

==========
Merge to M51: Prevent child frames from sending bad accessibility events.

A recent change in M51 to have a separate accessibility tree for
each frame resulted in a subtle regression, where the
BrowserAccessibilityManager for a child frame would send
accessibility events before it was fully connected to its parent
frame. Because of how accessibility events work on Windows, when
an external accessibility client tried to respond to those events
the target node wouldn't be found when calling get_accChild to
retrieve it.

The user-visible manifestation was that NVDA spoke "unknown" a lot,
in response to those bogus events.

The fundamental idea behind the fixes is that a native accessibility
event shouldn't be fired unless the target node is a direct descendant
of the HWND for that tab. This logic needs to handle all of the cases
that arise when we have a separate BrowserAccessibilityManager for
each frame. The specific issues were:

* BrowserAccessibilityManager::GetRootManager was walking up to a parent
  frame without checking that the parent frame linked back to itself.
* MaybeCallNotifyWinEvent was checking its own delegate's HWND rather
  than the target node's delegate's HWND.
* RenderFrameHostImpl::AccessibilityGetAcceleratedWidget should only
  return a valid HWND for the main frame's current frame host.

BUG=600145
CQ_INCLUDE_TRYBOTS=tryserver.chromium.linux:linux_site_isolation

Review URL: https://codereview.chromium.org/1892593003

Cr-Commit-Position: refs/heads/master@{#387681}
(cherry picked from commit fadccf76e38b76a0eb66f750ee668e89754596b7)

Committed:
https://chromium.googlesource.com/chromium/src/+/90106718b712cb8c4462c2f39bae...
==========

[dmazzoni, 2016-04-18 18:22:24]

Committed patchset #1 (id:1) manually as
90106718b712cb8c4462c2f39bae0e53a05a263b.