This is something that was implemented a long time ago, but it isn't covered in any spec, other browsers don't implement it and I don't know of any usage in the wild.
This doesn't work with OOP iframes, since what we're doing here requires the documents to be in the same process.
Given it isn't used or specified, the simplest solution is to just remove the behaviour altogether.
Differential Revision: https://phabricator.services.mozilla.com/D74628
This is not strictly related to this bug, but I'm touching the surrounding code and I've been confused by this on several occasions.
The previous comments suggested that NameFromAssociatedXULLabel (which uses XULLabelIterator) looks at child labels.
This is incorrect: XULLabelIterator only looks at <label control="id">.
The inclusion of child labels in the name comes from GetNameFromSubtree, which is called elsewhere.
Differential Revision: https://phabricator.services.mozilla.com/D74371
This was only used for richlistitems, but the richlistitem implementation of this property did the wrong thing in several cases.
The a11y engine's label computation code generally does a better job.
Where the label does need to be overridden in specific cases, we should use ARIA instead.
Differential Revision: https://phabricator.services.mozilla.com/D74370
This removes the need for FrameForPointOptions::IsRelativeToLayoutViewport,
and makes sure each call site of these functions indicates whether the
input point/rect is in visual or layout coordinates.
Several call sites were passing in layout coordinates without setting the
IsRelativeToLayoutViewport flag, which this patch corrects.
Differential Revision: https://phabricator.services.mozilla.com/D71705
This removes the need for FrameForPointOptions::IsRelativeToLayoutViewport,
and makes sure each call site of these functions indicates whether the
input point/rect is in visual or layout coordinates.
Several call sites were passing in layout coordinates without setting the
IsRelativeToLayoutViewport flag, which this patch corrects.
Differential Revision: https://phabricator.services.mozilla.com/D71705
When the tree is mutated, we set eGroupInfoDirty regardless of whether there is GroupInfo.
Previously, we cleared eGroupInfoDirty when updating GroupInfo, but not when creating it.
This meant that the flag was often still set, causing the cache to not be used a lot of the time.
Differential Revision: https://phabricator.services.mozilla.com/D72139
When an element with overflow:auto becomes scrollable, either by a style change or growing children, it should become focusable and fire a state change. Same in the inverse.
Differential Revision: https://phabricator.services.mozilla.com/D70561
--HG--
extra : moz-landing-system : lando
Changes to attributes such as disabled, contenteditable, and tabindex should cause FOCUSABLE
state changes to be fired when indeed the accessible gains or loses focusability.
Differential Revision: https://phabricator.services.mozilla.com/D70560
--HG--
extra : moz-landing-system : lando
For OOP iframe documents, we can't support NODE_CHILD_OF in the usual way, since the iframe resides in a different process.
Previously, we incorrectly returned the application accessible.
This was breaking focus ancestry walking for JAWS.
Instead, don't expose NODE_CHILD_OF at all in this case.
This is fine because the client will then request the parent instead, which will be correctly handled by platform/AccessibleOrProxy code.
Differential Revision: https://phabricator.services.mozilla.com/D70163
--HG--
extra : moz-landing-system : lando
This adds both the role as well as calculation of the posinset, setsize, and level calculation if not provided by the author.
Differential Revision: https://phabricator.services.mozilla.com/D64590
--HG--
extra : moz-landing-system : lando
This covers most cycle collected objects which support weak references, but
not the ones which inherit from a cycle collected class and don't do any cycle
collection on their own.
Differential Revision: https://phabricator.services.mozilla.com/D63962
--HG--
extra : moz-landing-system : lando
This removes the need for explicit #ifdef NS_BUILD_REFCNT_LOGGING without
introducing user-defined destructors when it is not defined.
Also, some uses of virtual for declaring destructors are replaced by the
appropriate override declaration through these changes.
Differential Revision: https://phabricator.services.mozilla.com/D62604
--HG--
extra : moz-landing-system : lando
This removes the need for explicit #ifdef NS_BUILD_REFCNT_LOGGING without
introducing user-defined destructors when it is not defined.
Also, some uses of virtual for declaring destructors are replaced by the
appropriate override declaration through these changes.
Differential Revision: https://phabricator.services.mozilla.com/D62604
--HG--
extra : moz-landing-system : lando
Normally, XUL menupopups contain XUL menuitems, and XUL menuitems fire DOMMenuitemActive events from layout to manage a11y focus.
However, the new parent process select dropdown implementation uses a menulist containing div elements instead of XUL menuitems.
DOMMenuItemActive doesn't work for div elements because we check Accessible::ContainerWidget(), and that doesn't know to return the menupopup for div elements.
Since aria-activedescendant is the more web standard way to handle this, the new select dropdown implementation uses aria-activedescendant.
Differential Revision: https://phabricator.services.mozilla.com/D62677
--HG--
extra : moz-landing-system : lando
Currently, only documents dispatch scroll events when in reality any
element can have scrollable overflows.
Differential Revision: https://phabricator.services.mozilla.com/D62665
--HG--
extra : moz-landing-system : lando
`nsRange` instances are allocated a lot in the heap especially by editor and
spellchecker. The allocation cost is too bad for benchmarks. Therefore,
we should reuse released instances as far as possible. For managing it in
static factory methods of `nsRange`, we need to hide `nsRange` constructor.
Differential Revision: https://phabricator.services.mozilla.com/D61237
--HG--
extra : moz-landing-system : lando
This means that for any other ARIA role, we will expose the DOCUMENT role on the DocAccessible.
Differential Revision: https://phabricator.services.mozilla.com/D60632
--HG--
extra : moz-landing-system : lando
On Windows, if the top level document hasn't received its parent COM proxy yet, sending constructors for child documents will be deferred.
If an OuterDocAccessible for an OOP iframe is created inside a child document before its constructor is sent, we must also defer the call to BrowserBridgeChild::SendSetEmbedderAccessible.
previously, we tried to send the embedder before the document constructor was sent, causing a crash.
Differential Revision: https://phabricator.services.mozilla.com/D59832
--HG--
extra : moz-landing-system : lando
After bug 981248, <input type="number"> no longer has an anonymous text input.
Instead, the <input type="number"> itself manages the text.
Previously, the a11y code which fired value change events for text changes only did this for combo boxes and role ENTRY.
This meant a value change event was no longer fired for <input type="number">.
This condition has now been extended to include role SPINBUTTON.
This fixes reporting of <input type="number"> changes for JAWS.
Differential Revision: https://phabricator.services.mozilla.com/D60101
--HG--
extra : moz-landing-system : lando
It is unexpected (see bug) that a -moz-box is affected by baseline alignment.
Make -moz-box be block-outside, and -moz-inline-box be inline-outside, instead
of the bespoke thing we have now.
This is more similar to everything else, and fixes the bug.
Differential Revision: https://phabricator.services.mozilla.com/D58726
--HG--
extra : moz-landing-system : lando
It is unexpected (see bug) that a -moz-box is affected by baseline alignment.
Make -moz-box be block-outside, and -moz-inline-box be inline-outside, instead
of the bespoke thing we have now.
This is more similar to everything else, and fixes the bug.
Differential Revision: https://phabricator.services.mozilla.com/D58726
--HG--
extra : moz-landing-system : lando
In a follow-up commit a new `ComparePoints` method with cleaner
arguments and return value will be added.
Differential Revision: https://phabricator.services.mozilla.com/D55295
--HG--
extra : moz-landing-system : lando
The inclusions were removed with the following very crude script and the
resulting breakage was fixed up by hand. The manual fixups did either
revert the changes done by the script, replace a generic header with a more
specific one or replace a header with a forward declaration.
find . -name "*.idl" | grep -v web-platform | grep -v third_party | while read path; do
interfaces=$(grep "^\(class\|interface\).*:.*" "$path" | cut -d' ' -f2)
if [ -n "$interfaces" ]; then
if [[ "$interfaces" == *$'\n'* ]]; then
regexp="\("
for i in $interfaces; do regexp="$regexp$i\|"; done
regexp="${regexp%%\\\|}\)"
else
regexp="$interfaces"
fi
interface=$(basename "$path")
rg -l "#include.*${interface%%.idl}.h" . | while read path2; do
hits=$(grep -v "#include.*${interface%%.idl}.h" "$path2" | grep -c "$regexp" )
if [ $hits -eq 0 ]; then
echo "Removing ${interface} from ${path2}"
grep -v "#include.*${interface%%.idl}.h" "$path2" > "$path2".tmp
mv -f "$path2".tmp "$path2"
fi
done
fi
done
Differential Revision: https://phabricator.services.mozilla.com/D55443
--HG--
extra : moz-landing-system : lando
Initially this was going to be a simple cleanup: Remove some useless namespaces
here and there and so on, remove `using` statements from the header and so on.
But unfortunately, DOMIntersectionObserver.h (which is included in Element.h,
unnecessarily) ended up exposing `Element` unnamespaced to a lot of code, so I
had to fix that.
Differential Revision: https://phabricator.services.mozilla.com/D55316
--HG--
extra : moz-landing-system : lando
A XUL <label control="id"> can refer to an HTML element.
Keyboard and mouse support for this already works, but previously, this wasn't being exposed via accessibility APIs.
1. Split the code to get the name from an associated XUL label out of Accessible::XULElmName into a new function Accessible::NameFromAssociatedXULLabel.
2. Use NameFromAssociatedXULLabel for HTMl elements.
3. Update AccessKey and RelationByType to support HTML elements with associated XUL labels.
4. Rename accessible/tests/mochitest/actions/test_keys_menu.xhtml to test_keys.xhtml so it can cover accessKey outside of menus.
5. Add tests.
Differential Revision: https://phabricator.services.mozilla.com/D55057
--HG--
rename : accessible/tests/mochitest/actions/test_keys_menu.xhtml => accessible/tests/mochitest/actions/test_keys.xhtml
extra : moz-landing-system : lando
Sub classes of `nsITextControlElement` are only `HTMLInputElement` and
`HTMLTextAreaElement`. And both base class is
`nsGenericHTMLFormElementWithState`. Therefore, we can make
`nsITextControlElement` inherit `nsGenericHTMLFormElementWithState` and
make `HTMLInputElement` and `HTMLTextAreaElement` inherit
`nsITextControlElement`. Then, we can get rid of a lot of QI between
`nsINode`/`nsIContent`/`Element` and `nsITextControlElement` (and note that
some of them in a hot path).
Additionally, this patch renames `nsITextControlElement` to
`mozilla::TextControlElement`.
Differential Revision: https://phabricator.services.mozilla.com/D54330
--HG--
rename : dom/html/nsITextControlElement.h => dom/html/TextControlElement.h
extra : moz-landing-system : lando
Sub classes of `nsITextControlElement` are only `HTMLInputElement` and
`HTMLTextAreaElement`. And both base class is
`nsGenericHTMLFormElementWithState`. Therefore, we can make
`nsITextControlElement` inherit `nsGenericHTMLFormElementWithState` and
make `HTMLInputElement` and `HTMLTextAreaElement` inherit
`nsITextControlElement`. Then, we can get rid of a lot of QI between
`nsINode`/`nsIContent`/`Element` and `nsITextControlElement` (and note that
some of them in a hot path).
Additionally, this patch renames `nsITextControlElement` to
`mozilla::TextControlElement`.
Differential Revision: https://phabricator.services.mozilla.com/D54330
--HG--
rename : dom/html/nsITextControlElement.h => dom/html/TextControlElement.h
extra : moz-landing-system : lando
This really shouldn't be possible.
All XUL trees should have nsIDOMXULMultiSelectControlElement, and the tree is focused at this point, so it shouldn't be dying.
Nevertheless, this sometimes happens in the wild and was causing crashes.
Differential Revision: https://phabricator.services.mozilla.com/D53373
--HG--
extra : moz-landing-system : lando
If an embed or object doesn't specify a URL (or specifies a URL which isn't web content), it won't be created as an OuterDocAccessible.
For example, an embed with no src will be created as a generic HyperTextAccessible.
If the URL later changes to refer to web content, we must recreate as an OuterDocAccessible.
Previously, we didn't recreate, which was causing an assertion and may have caused other strange issues as well.
Differential Revision: https://phabricator.services.mozilla.com/D52292
--HG--
extra : moz-landing-system : lando
nsXULWindow is no longer XUL specific and is somewhat confusing name.
Differential Revision: https://phabricator.services.mozilla.com/D51486
--HG--
rename : xpfe/appshell/nsXULWindow.cpp => xpfe/appshell/AppWindow.cpp
rename : xpfe/appshell/nsXULWindow.h => xpfe/appshell/AppWindow.h
rename : xpfe/appshell/nsIXULWindow.idl => xpfe/appshell/nsIAppWindow.idl
extra : moz-landing-system : lando
nsXULWindow is no longer XUL specific and is somewhat confusing name.
Differential Revision: https://phabricator.services.mozilla.com/D51486
--HG--
rename : xpfe/appshell/nsXULWindow.cpp => xpfe/appshell/AppWindow.cpp
rename : xpfe/appshell/nsXULWindow.h => xpfe/appshell/AppWindow.h
rename : xpfe/appshell/nsIXULWindow.idl => xpfe/appshell/nsIAppWindow.idl
extra : moz-landing-system : lando
nsXULWindow is no longer XUL specific and is somewhat confusing name.
Differential Revision: https://phabricator.services.mozilla.com/D51486
--HG--
rename : xpfe/appshell/nsXULWindow.cpp => xpfe/appshell/AppWindow.cpp
rename : xpfe/appshell/nsXULWindow.h => xpfe/appshell/AppWindow.h
rename : xpfe/appshell/nsIXULWindow.idl => xpfe/appshell/nsIAppWindow.idl
extra : moz-landing-system : lando
Sometimes, depending on how children were changed, children might be in the insertion list out of order; e.g. [child2, child1].
It's also possible that an earlier child (child1 in the above example) is being moved out of another container.
When processing the earlier insertion (child2), we'll determine we need to move it within its parent and will fetch its new previous sibling so we can move it into the right place.
However, in this case, the new previous sibling (child1) will be in the wrong container.
We can't move in that case; the new previous sibling's index in parent will obviously be wrong, since it's relative to the wrong container.
Therefore, we just skip the move.
Since the previous sibling (child1) is later in the insertion list, the ordering will be corrected when we process that insertion.
Differential Revision: https://phabricator.services.mozilla.com/D51037
--HG--
extra : moz-landing-system : lando
Lazily creating children might cause us to make layout calls at unsafe times.
Differential Revision: https://phabricator.services.mozilla.com/D47361
--HG--
extra : moz-landing-system : lando
This is an extension protocol that can be used for platform specific
API (ie. AccessibleWrap methods).
I'm not thrilled with the seperate constructor for the sub-protocol.
This means that the parent won't have the actor upon DocAccessibleParent
construction, and some timing bugs can arise because of the extra round
trip. It would be cool if both actors could be co-created, but that
would require ManagedEndpoint, and for PBrowser to manage them both. I
don't want to expose this to PBrowser.
Differential Revision: https://phabricator.services.mozilla.com/D37955
--HG--
extra : moz-landing-system : lando
And also this patch moves `TextEditRules::HandleNewLines()` and
`TextEditRules::DontEchoPassword()` to `TextEditor`.
Differential Revision: https://phabricator.services.mozilla.com/D45298
--HG--
extra : moz-landing-system : lando
This is an extension protocol that can be used for platform specific
API (ie. AccessibleWrap methods).
I'm not thrilled with the seperate constructor for the sub-protocol.
This means that the parent won't have the actor upon DocAccessibleParent
construction, and some timing bugs can arise because of the extra round
trip. It would be cool if both actors could be co-created, but that
would require ManagedEndpoint, and for PBrowser to manage them both. I
don't want to expose this to PBrowser.
Differential Revision: https://phabricator.services.mozilla.com/D37955
--HG--
extra : moz-landing-system : lando
This is an extension protocol that can be used for platform specific
API (ie. AccessibleWrap methods).
I'm not thrilled with the seperate constructor for the sub-protocol.
This means that the parent won't have the actor upon DocAccessibleParent
construction, and some timing bugs can arise because of the extra round
trip. It would be cool if both actors could be co-created, but that
would require ManagedEndpoint, and for PBrowser to manage them both. I
don't want to expose this to PBrowser.
Differential Revision: https://phabricator.services.mozilla.com/D37955
--HG--
extra : moz-landing-system : lando
This assures that a node that has already been inserted in a shadow root
subtree does not get erroneously reinserted into the top container.
Differential Revision: https://phabricator.services.mozilla.com/D44880
--HG--
extra : moz-landing-system : lando
Pruning these meant that `<span><br></span>` wasn't represented in the tree or rendered text at all.
This meant that lines were merged together in NVDA browse mode; e.g. in CI build logs on Gitlab.
The reason we started pruning these is that they were causing invalid line offsets to be returned for affected lines (bug 899433).
This patch also fixes this problem in HyperTextAccessible::FindOffset.
Differential Revision: https://phabricator.services.mozilla.com/D44815
--HG--
extra : moz-landing-system : lando
All calls to `profiler_add_marker()` (outside of the profilers code) are
now replaced by either:
- `PROFILER_ADD_MARKER(name, categoryPair)`
- `PROFILER_ADD_MARKER_WITH_PAYLOAD(name, categoryPair, TypeOfMarkerPayload,
(payload, ..., arguments))`
This makes all calls consistent, and they won't need to prefix the category pair
with `JS::ProfilingCategoryPair::`.
Also it will make it easier to add (and later remove) internal-profiling
instrumentation (bug 1576550), and to replace heap-allocated payloads with
stack-allocated ones (bug 1576555).
Differential Revision: https://phabricator.services.mozilla.com/D43588
--HG--
extra : moz-landing-system : lando
This patch does several things:
1. If there is a change to a host or a slot, check the slottable
elements to see if they are rendered in the tree. Remove them if not.
2. Check slot elements' fallback content if it is rendered and remove if
not.
3. Allow accessibles to be reinserted into a different parent or index.
Differential Revision: https://phabricator.services.mozilla.com/D43489
--HG--
extra : moz-landing-system : lando
Converts ui.key.generalAccessKey, ui.key.chromeAccess, and ui.key.contentAccess to static prefs. Updates usages.
Differential Revision: https://phabricator.services.mozilla.com/D42392
--HG--
extra : moz-landing-system : lando
The DOM mutation observer method is called during frame destruction
which is not a good state to be in when constructing and dispatching events.
Differential Revision: https://phabricator.services.mozilla.com/D41825
--HG--
extra : moz-landing-system : lando
All .xul files have been loading as HTMLDocuments for a few weeks now, so
it should be safe to remove the XULDocument implementation.
Differential Revision: https://phabricator.services.mozilla.com/D41238
--HG--
extra : moz-landing-system : lando
Removing an Accessible removes descendants in the a11y tree.
However, there may be DOM descendants which have been relocated elsewhere in the a11y tree.
Their DOM nodes are now hidden as well, so we need to remove those Accessibles too.
In addition to Accessibles remaining in the tree when they shouldn't, failing to remove relocated Accessibles caused problems later on when a relocated Accessible was shown with new descendants.
Differential Revision: https://phabricator.services.mozilla.com/D41178
--HG--
extra : moz-landing-system : lando
We need to visit the descendants of a container that has no accessible,
but has accessible children.
Also added a test for delayed removal where we can put all these nasty
cases.
Differential Revision: https://phabricator.services.mozilla.com/D41059
--HG--
extra : moz-landing-system : lando
We naively remove and then recreate accessibles when their content's
frame is reconstructed. By delaying the removal until we are certain the
content does not have a new layout frame, we can cut down on redundant
recreations.
When reconstructed content is re-inserted we can check it and its
subtree for missing frames and prune those accessibles from the tree.
Differential Revision: https://phabricator.services.mozilla.com/D38380
--HG--
extra : moz-landing-system : lando
This is the first step in making it possible to return remote WindowProxy
objects from window.open() and related APIs.
This patch also incidentally fixes a bug where getContentWindowOrOpenURI
returned the top-level browser window rather than the new content window when
passed OPEN_NEWWINDOW for the `aWhere` parameter. This was not the expected
behavior, and was a potentially major footgun for any new users who expected
to always get the content window for the URL they were loading, rather than
sometimes getting a chrome browser window instead.
For now, that case just returns null, which is only a minor footgun, rather
than the major one we had before.
Differential Revision: https://phabricator.services.mozilla.com/D35688
--HG--
extra : moz-landing-system : lando
Editor creates a `<br>` element when it's root element is empty.
Then, it's stored by `TextEditRules::mBogusNode` and used for checking
whether the editor is empty quickly. However, this `<br>` element has
`mozeditorbogusnode` attribute whose value is `true`. However, adding or
removing the attribute is not cheap and web apps can refer such illegal
attribute.
Therefore, this patch makes `HTMLBRElement` take a specific flag whether
it's a bogus node or not. However, this means that this hacky thing will be
exposed outside editor module. For making what is the bogus node clearer,
this patch calls the such `<br>` elements as "padding `<br>` element for
empty editor". So, this patch also includes a lot of renaming methods and
variables, and modifying related comments.
Differential Revision: https://phabricator.services.mozilla.com/D39857
--HG--
extra : moz-landing-system : lando
Normally, the OuterDocAccessible is created first and the DocAccessibleParent for a remote document is created after that.
So, we get the OuterDocAccessible and call DocAccessibleParent::SendParentCOMProxy when the DocAccessibleParent is constructed (BrowserParent::RecvPDocAccessibleConstructor).
However, sometimes, the OuterDocAccessible is created *after* the DocAccessibleParent.
This sometimes happens for extension popups, for example.
In that case, we previously never sent the parent COM proxy.
Aside from leaving the remote document with a null parent, this also meant we never sent any events for the document, since events are buffered for remote documents until the parent COM proxy is received.
This effectively left the remote document (e.g. extension popup) inaccessible.
Now, we also call SendParentCOMProxy in the OuterDocAccessible constructor.
Note that this doesn't result in duplicates because if the OuterDocAccessible was created first, there won't be a DocAccessibleParent for the remote document yet, so this code won't run.
That said, if the OuterDocAccessible is recreated (e.g. due to frame reconstruction), we may call SendParentCOMProxy again.
This should be okay, but it required an assertion in DocAccessibleChild::RecvParentCOMProxy to be tweaked.
Differential Revision: https://phabricator.services.mozilla.com/D40358
--HG--
extra : moz-landing-system : lando
It seems a bit more sensible to me that if any filtering needs to happen
from content insertions, it should happen in the doc and not the
notification controller.
Differential Revision: https://phabricator.services.mozilla.com/D40132
--HG--
extra : moz-landing-system : lando
Previously, we would always calculate the name for tr elements from their descendants unconditionally. Assistive technologies aren't using this information, moreover, it causes problems if the name gets too long, for example in layout tables.
We now only calculate the name if the tr element has an explicit ARIA role.
Differential Revision: https://phabricator.services.mozilla.com/D39314
--HG--
extra : moz-landing-system : lando
Previously, the target element for aria-activedescendant was retrieved by calling GetElementById on the owner document.
This meant that aria-activedescendant inside shadow DOM looked for ids in the owner document instead of the shadow DOM.
To fix this, use IDRefsIterator::GetElem instead.
Differential Revision: https://phabricator.services.mozilla.com/D38833
--HG--
extra : moz-landing-system : lando
On Windows, OuterDocAccessible::GetChildAt can return a proxy wrapper for a remote document.
These aren't real Accessibles and shouldn't be returned except to the Windows a11y code (which doesn't use eDeepestChild).
Calling ChildAtPoint on these will crash!
Therefore, just return null in this case.
Differential Revision: https://phabricator.services.mozilla.com/D39135
--HG--
extra : moz-landing-system : lando
Previously, BrowserBridgeChild::SendSetEmbedderAccessible was only called when an OuterDocAccessible was constructed.
However, it's also possible that the BrowserBridgeChild is created *after* the OuterDocAccessible.
Therefore, we must also do this when a BrowserBridgeChild is created if the OuterDocAccessible already exists.
Differential Revision: https://phabricator.services.mozilla.com/D34474
--HG--
extra : moz-landing-system : lando
Previously, BrowserBridgeChild::SendSetEmbedderAccessible was only called when an OuterDocAccessible was constructed.
However, it's also possible that the BrowserBridgeChild is created *after* the OuterDocAccessible.
Therefore, we must also do this when a BrowserBridgeChild is created if the OuterDocAccessible already exists.
Differential Revision: https://phabricator.services.mozilla.com/D34474
--HG--
extra : moz-landing-system : lando
Fixes test 'accessible/tests/mochitest/relations/test_general.xul' when
loaded as XHTML.
Differential Revision: https://phabricator.services.mozilla.com/D34655
--HG--
extra : moz-landing-system : lando
Aside from the parent being needed by the client, this is also important because events from the embedded document are deferred until the parent COM proxy is received.
As part of this, we no longer try to send the parent COM proxy during construction of an OuterDocAccessible in the parent process.
This was previously a no-op anyway, as DocAccessibleParent::SendParentCOMProxy called DocAccessible::GetAccessible for the frame element, which would have returned null because the accessible isn't bound to the document until *after* it is constructed.
Changing this to directly pass the OuterDocAccessible was causing assertions in content processes, since it sometimes meant the parent COM proxy was sent twice, which is precisely what the assertion is protecting against.
Instead, the parent proxy is sent in Browserparent::RecvPDocAccessibleConstructor as it always was.
Differential Revision: https://phabricator.services.mozilla.com/D32284
--HG--
extra : moz-landing-system : lando
Aside from the parent being needed by the client, this is also important because events from the embedded document are deferred until the parent COM proxy is received.
Differential Revision: https://phabricator.services.mozilla.com/D32284
--HG--
extra : moz-landing-system : lando
Eitan Isaacson
James Teh
Botond Ballo
Mirko Brodesser
Jonathan Watt
Morgan Reschenberg
Csoregi Natalia
Simon Giesecke
Noemi Erli
Eric Rahm
Marco Zehe
Emilio Cobos Álvarez
Andrew McCreight
Ciure Andrei
Kris Maglione
Dorel Luca
Masayuki Nakano
Colomban Wendling
Bogdan Tara
Kirk Steuber
Gabriele Svelto
Sylvestre Ledru
Coroiu Cristina
Brendan Dahl
Mihai Alexandru Michis
Edgar Chen
Alexander Surkov
Daniel Varga
Hiroyuki Ikezoe
Gerald Squelart
Maliha Islam
kriswright
Gautham Velchuru
Mike Hommey
Kannan Vijayan
Boris Zbarsky
Cameron McCormack
Narcis Beleuzu
Andreea Pavel