1334966 - Crash in mozilla::dom::TabParent::GetTopLevelDocAccessible

Status: VERIFIED FIXED

(Core :: Disability Access APIs, defect)

Description

[Marco Zehe (:MarcoZ)]

This bug was filed from the Socorro interface and is 
report bp-f5ab4b55-be44-432e-b642-e86222170130.
=============================================================

This bug has actually morphed from what was in bug 1334059. The steps are the same. With NVDA running and E10S enabled:

1. Visit https://taz.de/Politik/Deutschland/!p4616/
2. Focus the link "Gesellschaft" in the big list of categories and sub categories.
3. Press Ctrl+Enter to open that in a new tab.
4. Crash.

There's also a followup crash that gets submitted along with the above one:
https://crash-stats.mozilla.com/report/index/4a98417a-502b-48cf-ae17-01a072170130

The signature seems to be identical, but this is a separate report that gets submitted alongside the first.

Comment 1

[Trevor Saunders (:tbsaunde)]

Attachment: make TabParent::GetTopLevelDocAccessible() only return documents that are top level

There can be cases where a non top level document currently has no parent
 document, for example when a child doc has been unbound from its parent but
 not yet reattached to a new outer doc.

Comment 2

[Eitan Isaacson [:eeejay]]

Comment on attachment 8831602 [details] [diff] [review]
make TabParent::GetTopLevelDocAccessible() only return documents that are top level

Review of attachment 8831602 [details] [diff] [review]:
-----------------------------------------------------------------

::: dom/ipc/TabParent.cpp
@@ +969,5 @@
>    // document accessible.
>    const ManagedContainer<PDocAccessibleParent>& docs = ManagedPDocAccessibleParent();
>    for (auto iter = docs.ConstIter(); !iter.Done(); iter.Next()) {
>      auto doc = static_cast<a11y::DocAccessibleParent*>(iter.Get()->GetKey());
> +    if (doc->IsTopLevel()) {

If we change this method, shouldn't we also change GetProxiedAccessibleInSubtree?

Instead of the if block with aDoc->IsTopLevel() and a recursive call, you can simply get the TabParent, and call GetTopLevelDocAccessible().

Comment 3

[Trevor Saunders (:tbsaunde)]

(In reply to Eitan Isaacson [:eeejay] from comment #2)
> Comment on attachment 8831602 [details] [diff] [review]
> make TabParent::GetTopLevelDocAccessible() only return documents that are
> top level
> 
> Review of attachment 8831602 [details] [diff] [review]:
> -----------------------------------------------------------------
> 
> ::: dom/ipc/TabParent.cpp
> @@ +969,5 @@
> >    // document accessible.
> >    const ManagedContainer<PDocAccessibleParent>& docs = ManagedPDocAccessibleParent();
> >    for (auto iter = docs.ConstIter(); !iter.Done(); iter.Next()) {
> >      auto doc = static_cast<a11y::DocAccessibleParent*>(iter.Get()->GetKey());
> > +    if (doc->IsTopLevel()) {
> 
> If we change this method, shouldn't we also change
> GetProxiedAccessibleInSubtree?
> 
> Instead of the if block with aDoc->IsTopLevel() and a recursive call, you
> can simply get the TabParent, and call GetTopLevelDocAccessible().

That would have been a correct implementation before this too, but I suspect a fast path may be worth while since iterating over a hash table to find something you already have is pretty silly.

Comment 4

[Eitan Isaacson [:eeejay]]

Comment on attachment 8831602 [details] [diff] [review]
make TabParent::GetTopLevelDocAccessible() only return documents that are top level

Review of attachment 8831602 [details] [diff] [review]:
-----------------------------------------------------------------

I guess I would have written that method a bit differently without the recursion. But its not wrong.

Comment 5

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/mozilla-inbound/rev/2467b35c59b2
make TabParent::GetTopLevelDocAccessible() only return documents that are top level r=eeejay

Comment 6

[Wes Kocher (:KWierso) (Not reading bugmail; email directly if needed)]

https://hg.mozilla.org/mozilla-central/rev/2467b35c59b2

Comment 7

[Paul Silaghi, QA [:pauly]]

I'm not able to reproduce the initial issue on 54.0a1 (2017-01-30) Win 10, but I think we're safe to mark this as verified since there are no crashes in Socorro on builds newer than 2017-01-31.