Allow the IAccessible parent to be known late in the game.

Allow the IAccessible parent to be known late in the game.

In the case of a tab loading in the background, accessibility
notifications may arrive from the renderer before the tab's WebContents
is added to a WebView. In this case, the accessible parent isn't yet
known. Handle this case by allowing the RWHVA's
BrowserAccessibilityManager to be created without an accessible parent
and then receive that parent (from a WebContentsImpl) when the
WebContents is finally attached to a WebView.

BUG=242524
[email protected]

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

[grt (UTC plus 2), 2013-05-22 22:00:28]

Here's a band-aid to make cpu@ happy. Please loop in sky@ or another
content/browser OWNER review if this looks good to you (and passes the trybots).
Thanks.

[dmazzoni, 2013-05-22 23:08:04]

lgtm with the suggestion that we change NOTREACHED to LOG(ERROR), see below

+sky

https://codereview.chromium.org/15744014/diff/1/content/browser/accessibility...
File content/browser/accessibility/browser_accessibility_win.cc (right):

https://codereview.chromium.org/15744014/diff/1/content/browser/accessibility...
content/browser/accessibility/browser_accessibility_win.cc:498: NOTREACHED();
Won't a NOTREACHED also halt a debug build? I'm a bit surprised that you would
actually hit the DCHECK in render_widget_host_view_aura but you wouldn't hit
this one just a moment later.

It probably depends on what mode you're in. On desktop mode, the RWHVA code will
get hit but this code probably won't execute. In Metro mode, Windows will
probably explore the accessibility object and call getParent, leading to this
assertion.

Basically, if you need a quick fix, just change this to a LOG(ERROR) with a
TODO, or let's spend a little more effort and fix it.

[sky, 2013-05-23 00:09:24]

https://codereview.chromium.org/15744014/diff/1/content/browser/accessibility...
File content/browser/accessibility/browser_accessibility_win.cc (right):

https://codereview.chromium.org/15744014/diff/1/content/browser/accessibility...
content/browser/accessibility/browser_accessibility_win.cc:498: NOTREACHED();
If this is a valid state then you should return (meaning no NOTREACHED). If this
is not a valid state then you need to investigate why we're hitting it.

[grt (UTC plus 2), 2013-05-23 14:10:32]

Thanks for the comments. I believe I've turned the band-aid into a proper fix
for the bug. The NOTREACHED() should never be reached now. Please take another
look.

[dmazzoni, 2013-05-23 14:53:35]

Thanks for the right fix!

This is the right idea - but it's still possible the NOTREACHED can be hit. Once
BrowserAccessibilityManager is created, it may call NotifyWinEvent at
any time, which could result in getParent getting called on the target
object, even though that object isn't reachable from RWHVA.

There are only three functions where NotifyWinEvent is called in
content/browser/accessibility - I'd just guard each of those and
not call NotifyWinEvent if the parent is NULL, and that should do it.

https://codereview.chromium.org/15744014/diff/16001/content/browser/renderer_...
File content/browser/renderer_host/render_widget_host_impl.cc (right):

https://codereview.chromium.org/15744014/diff/16001/content/browser/renderer_...
content/browser/renderer_host/render_widget_host_impl.cc:2325: if (view_ &&
view_->GetBrowserAccessibilityManager()) {
Rather than add an additional dependency on BrowserAccessibilityManager here, I
think it'd be cleaner to call SetParentNativeViewAccessible on view_.

[grt (UTC plus 2), 2013-05-23 18:30:47]

Thanks for the suggestions, Dominic. I've consolidated calls to NotifyWinEvent
into a new method on BrowserAccessibilityManagerWin that checks for
parent_iaccessible before notifying. I also changed RenderWidgetHostImpl so that
it calls through its RenderWidgetHostViewPort* to give the accessible parent to
the RenderWidgetHostViewAura. This seems a bit heavy-handed, so let me know if
there's a better way that I overlooked.

[dmazzoni, 2013-05-23 18:41:51]

lgtm with nit

content/browser/accessibility looks fine - I'll defer to Scott on whether using
RWHVPort is the right abstraction.

https://codereview.chromium.org/15744014/diff/26001/content/browser/accessibi...
File content/browser/accessibility/browser_accessibility_manager_win.h (right):

https://codereview.chromium.org/15744014/diff/26001/content/browser/accessibi...
content/browser/accessibility/browser_accessibility_manager_win.h:43: void
SignalEventForChild(DWORD event, LONG child_id);
Let's just call this MaybeCallNotifyWinEvent, then you don't have to document
what |event| and |child_id| are since they're just passed through to
NotifyWinEvent.

[grt (UTC plus 2), 2013-05-23 18:52:43]

Thanks.

sky: PTAL, specifically the way I plumbed through RenderWidgetHostViewPort.
Please see Dominic's and my comments earlier in the thread for details.

https://codereview.chromium.org/15744014/diff/26001/content/browser/accessibi...
File content/browser/accessibility/browser_accessibility_manager_win.h (right):

https://codereview.chromium.org/15744014/diff/26001/content/browser/accessibi...
content/browser/accessibility/browser_accessibility_manager_win.h:43: void
SignalEventForChild(DWORD event, LONG child_id);
On 2013/05/23 18:41:51, Dominic Mazzoni wrote:
> Let's just call this MaybeCallNotifyWinEvent, then you don't have to document
> what |event| and |child_id| are since they're just passed through to
> NotifyWinEvent.

Done.

[sky, 2013-05-23 21:16:07]

https://codereview.chromium.org/15744014/diff/29018/content/browser/accessibi...
File content/browser/accessibility/browser_accessibility_win.cc (right):

https://codereview.chromium.org/15744014/diff/29018/content/browser/accessibi...
content/browser/accessibility/browser_accessibility_win.cc:495: // This can only
happen if the BrowserAccessibilityManagerWin was created
I this should never happen, then DCHECK(parent)

[grt (UTC plus 2), 2013-05-24 01:15:16]

https://codereview.chromium.org/15744014/diff/29018/content/browser/accessibi...
File content/browser/accessibility/browser_accessibility_win.cc (right):

https://codereview.chromium.org/15744014/diff/29018/content/browser/accessibi...
content/browser/accessibility/browser_accessibility_win.cc:495: // This can only
happen if the BrowserAccessibilityManagerWin was created
On 2013/05/23 21:16:07, sky wrote:
> I this should never happen, then DCHECK(parent)

Are you suggesting that I replace lines 494-500 with DCHECK(parent), or only
line 498? If the former, I don't see how that's an improvement over what's here.
The unexpected happens. May as well handle it gracefully in release builds.

[grt (UTC plus 2), 2013-05-24 13:22:37]

https://codereview.chromium.org/15744014/diff/29018/content/browser/accessibi...
File content/browser/accessibility/browser_accessibility_win.cc (right):

https://codereview.chromium.org/15744014/diff/29018/content/browser/accessibi...
content/browser/accessibility/browser_accessibility_win.cc:495: // This can only
happen if the BrowserAccessibilityManagerWin was created
On 2013/05/24 01:15:17, grt wrote:
> On 2013/05/23 21:16:07, sky wrote:
> > I this should never happen, then DCHECK(parent)
> 
> Are you suggesting that I replace lines 494-500 with DCHECK(parent), or only
> line 498? If the former, I don't see how that's an improvement over what's
here.
> The unexpected happens. May as well handle it gracefully in release builds.

Upon further thought, I think CHECK(parent) is better. Although I hope it won't
happen, I think it's better that we get meaningful crash reports so we learn
about it rather than have either a silent S_FALSE or an unpredictable crash
later on. What do you think?

[dmazzoni, 2013-05-24 13:50:15]

On 2013/05/24 13:22:37, grt wrote:
> Upon further thought, I think CHECK(parent) is better. Although I hope it
won't
> happen, I think it's better that we get meaningful crash reports so we learn
> about it rather than have either a silent S_FALSE or an unpredictable crash
> later on. What do you think?

Fine with me. If there are future regressions we'll catch them much faster if
it's a CHECK.

[grt (UTC plus 2), 2013-05-24 15:53:33]

On 2013/05/24 13:50:15, Dominic Mazzoni wrote:
> On 2013/05/24 13:22:37, grt wrote:
> > Upon further thought, I think CHECK(parent) is better. Although I hope it
> won't
> > happen, I think it's better that we get meaningful crash reports so we learn
> > about it rather than have either a silent S_FALSE or an unpredictable crash
> > later on. What do you think?
> 
> Fine with me. If there are future regressions we'll catch them much faster if
> it's a CHECK.

Done. What do you think, Scott?

[sky, 2013-05-24 16:06:03]

LGTM

[commit-bot: I haz the power, 2013-05-24 16:07:41]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/[email protected]/15744014/43001

[commit-bot: I haz the power, 2013-05-24 16:15:51]

Retried try job too often on chromium_presubmit for step(s) presubmit
http://build.chromium.org/p/tryserver.chromium/buildstatus?builder=chromium_p...

[grt (UTC plus 2), 2013-05-24 17:17:53]

+joi for content/port OWNERS review.

[Jói, 2013-05-24 21:33:03]

LGTM for //content/port.

[commit-bot: I haz the power, 2013-05-24 22:09:54]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/[email protected]/15744014/43001

[commit-bot: I haz the power, 2013-05-25 01:14:52]

Change committed as 202247