In bug 1525101, autocomplete-richlistbox-popup was converted to a Custom Element.
This means we can no longer use do_QueryInterface to get nsIAutoCompletePopup.
Instead, we must use Element::AsAutoCompletePopup.
This fixes accessibility focus for these autocompletes.
Differential Revision: https://phabricator.services.mozilla.com/D38158
--HG--
extra : moz-landing-system : lando
OuterDocAccessible can return a DocProxyAccessibleWrap or RemoteIframeDocProxyAccessibleWrap as a child.
Accessible::ChildAtPoint on an ancestor might retrieve this proxy and call Bounds() on it.
This will crash on a proxy, so we override it on these document proxies to do nothing.
Differential Revision: https://phabricator.services.mozilla.com/D38256
--HG--
extra : moz-landing-system : lando
Even though a11y DLLs are not strictly "DLL blocking," I felt that it would
make sense to include them in our unified DLL blocklist. This patch delegates
much of that functionality to the unified blocklist code. Going forward, any
further blocklist entries for in-proc a11y DLLs should be added to
mozglue/build/WindowsDllBlocklistDefs.in via the A11yBlocklistEntry type.
Differential Revision: https://phabricator.services.mozilla.com/D37001
--HG--
extra : moz-landing-system : lando
For same-process iframe documents, this reorder event is fired by the content process.
This isn't possible when the document is in a different process to its embedder.
In this case, we need to fire it from the parent process when the embedded document accessible is added.
Differential Revision: https://phabricator.services.mozilla.com/D37352
--HG--
extra : moz-landing-system : lando
386947-1.xul, now has one assertion since we take a different code
path with chrome URL's and XBL files. The assertion is triggered since the
binding is invalid.
Differential Revision: https://phabricator.services.mozilla.com/D34542
--HG--
extra : moz-landing-system : lando
Previously, DocAccessibleParent::AddChildDoc used the presence of a BrowserBridgeParent to determine whether the child document was in a different process to the parent document.
While this is normally the case, there can be a point while the embedded document is loading where there is a temporary document in the same (embedder) process.
In this case, we tried to get the COM proxy for the child document.
For a child document in the same process, this isn't available yet, so this caused infinite recursion (stack overflow) in ProxyAccessible::GetCOMInterface.
Instead of using the presence of BrowserBridgeParent, first check whether the child document is at the top level of its content process.
If it isn't, the document is in the same process as its parent.
Also, add a DIAGNOSTIC_ASSERT to ProxyAccessible::GetCOMInterface which will fire if no COM proxy or MSAA child id has been set.
Previously, we just recursed infinitely and overflowed the stack in this case, which is painful to debug.
Differential Revision: https://phabricator.services.mozilla.com/D37344
--HG--
extra : moz-landing-system : lando
`NS_FRAME_IS_DIRTY` being set on a frame has always meant that that
frame and all of its descendants need to be reflowed. What the main
patch on this bug is changing is when it gets propagated to descendants;
prior to that patch it gets propagated during reflow, whereas after the
patch it gets propagated when the bit is set. This means that
`NS_FRAME_IS_DIRTY` is now (after the patch) a somewhat more reliable
indicator of whether a frame requires reflow than it was before.
However, this has a strange interaction with the particular sequence of
operations that test_list.html performs. In particular, test_list.html:
(1) makes a style change that requires reflow,
(2) flushes style (but not layout), and
(3) gets the name of an accessible whose layout was dirtied by the style change.
Getting this name ends up here:
```
nsTextFrame::GetRenderedText at layout/generic/nsTextFrame.cpp:9600
nsTextEquivUtils::AppendTextEquivFromTextContent at accessible/base/nsTextEquivUtils.cpp:127
nsTextEquivUtils::AppendFromAccessible at accessible/base/nsTextEquivUtils.cpp:174
nsTextEquivUtils::AppendFromAccessibleChildren at accessible/base/nsTextEquivUtils.cpp:162
nsTextEquivUtils::GetNameFromSubtree at accessible/base/nsTextEquivUtils.cpp:39
mozilla::a11y::Accessible::NativeName at accessible/generic/Accessible.cpp:1991
mozilla::a11y::HyperTextAccessible::NativeName at accessible/generic/HyperTextAccessible.cpp:1760
mozilla::a11y::Accessible::Name at accessible/generic/Accessible.cpp:149
mozilla::a11y::xpcAccessible::GetName at accessible/xpcom/xpcAccessible.cpp:245
NS_InvokeByIndex at xpcom/reflect/xptcall/md/unix/xptcinvoke_asm_x86_64_unix.S:106
```
What the main patch in the bug has changed is whether this `nsTextFrame`
has the `NS_FRAME_IS_DIRTY` bit set at this point. This means that
`GetRenderedText` will bail out without reporting the text, because the
frame is marked dirty.
On the assumption that this action -- getting accessible names while
frames are dirty -- is an artificial situation set up in the test and
not a real-world situation that we need to care about, I'm proposing
that we make the straightforward adjustment to the test: flush layout
in addition to flushing style at step (2) above, so that the test works
again. As long as that assumption is correct, I think this should be
fine. (I'd note that this is the *only* test that breaks as a result of
the patch.)
If, on the other hand, we actually do care about what accessible names
return while layout state is dirty and reflow is needed, we should
probably improve `nsTextFrame::GetRenderedText` so that it can somehow
report useful state even when `NS_FRAME_IS_DIRTY` is set, or something
else more complicated.
Differential Revision: https://phabricator.services.mozilla.com/D36423
--HG--
extra : moz-landing-system : lando
The conversion for "regular" <tabs> elements is straightforward, most of
the work here is to support the tab strip (the <tabs> element with the id
"tabbrowser-tabs"). The markup needed for the tab strip moves directly
into browser.xhtml and the construction/teardown logic is now explicitly
driven from gBrowser. There are many more little tweaks too numerous to
enumerate.
Differential Revision: https://phabricator.services.mozilla.com/D32855
--HG--
rename : browser/base/content/tabbrowser.xml => browser/base/content/tabbrowser-tabs.js
extra : source : c163881a80c9a032b40f7d965fad6a6850fcf8a4
extra : intermediate-source : a5c6deeda8a9475ac0268a4351417c8ff659c962
extra : histedit_source : 5eb8b3d14027f2aeca5c52534096837cd0343104%2Ca23a07ddd5e1fb8bd084644dd6db0ee028b7c4b4
A bunch of existing code assumes that <tab> elements are the immediate
and only children of a <tabs> element, and uses dom apis to traverse
relationships between these elements. To simplify conversion of <tabs>
to a custom element (and hopefully improve readability a bit at the same
time!), introduce new apis:
On <tab>
this.parentNode -> this.container
this.nextElementSibling -> this.container.findNextTab(...)
this.previousElementSibiling -> this.container.findNextTab(...)
On <tabs>
this.children -> this.allTabs
Differential Revision: https://phabricator.services.mozilla.com/D34648
--HG--
extra : source : f4e21e465f384b90fa1e768141c4db708748bf66
extra : histedit_source : 95d8a4242e8e04df9e29c2b647558d37e910b845
The conversion for "regular" <tabs> elements is straightforward, most of
the work here is to support the tab strip (the <tabs> element with the id
"tabbrowser-tabs"). The markup needed for the tab strip moves directly
into browser.xhtml and the construction/teardown logic is now explicitly
driven from gBrowser. There are many more little tweaks too numerous to
enumerate.
Differential Revision: https://phabricator.services.mozilla.com/D32855
--HG--
rename : browser/base/content/tabbrowser.xml => browser/base/content/tabbrowser-tabs.js
extra : rebase_source : 6b2b0ed9b01958d1b2db605ab300c4bebcaa461c
extra : source : c163881a80c9a032b40f7d965fad6a6850fcf8a4
A bunch of existing code assumes that <tab> elements are the immediate
and only children of a <tabs> element, and uses dom apis to traverse
relationships between these elements. To simplify conversion of <tabs>
to a custom element (and hopefully improve readability a bit at the same
time!), introduce new apis:
On <tab>
this.parentNode -> this.container
this.nextElementSibling -> this.container.findNextTab(...)
this.previousElementSibiling -> this.container.findNextTab(...)
On <tabs>
this.children -> this.allTabs
Differential Revision: https://phabricator.services.mozilla.com/D34648
--HG--
extra : rebase_source : affeda0295a5195124709f322de524aea3a28a3f
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
When a client wants to fetch all accessible children, the COM handler uses handlerProvider::get_AllChildren in the content process to optimize cross-process retrieval of all children.
This works fine for iframes rendered in the same content process, just as it does for other accessibles.
However, for out-of-process iframes, HandlerProvider::get_AllChildren will fail.
This is because we only send down an IDispatch COM proxy for the embedded document, but get_AllChildren will try to QueryInterface this to IAccessible2 to reduce QI calls from the parent process.
Because the content process is sandboxed, it can't make the outgoing COM call to QI the proxy from IDispatch to IAccessible2 and so it fails.
Since an iframe only has one child anyway, we don't need the bulk fetch optimization offered by HandlerChildEnumerator or even IEnumVARIANT.
Therefore, we explicitly tell the client this interface is not supported, which will cause the oleacc AccessibleChildren function to fall back to accChild.
Differential Revision: https://phabricator.services.mozilla.com/D34494
--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
The correct mapping for nsIAccessibleEvent::EVENT_TEXT_SELECTION_CHANGED
in ATK is text_selection_changed; not selection_changed. The latter is
meant for containers which support selection of child objects, such as
a menu or expanded select element.
Differential Revision: https://phabricator.services.mozilla.com/D34521
--HG--
extra : moz-landing-system : lando
James Teh
Dão Gottwald
Mihai Alexandru Michis
Coroiu Cristina
Gurzau Raul
Tom Ritter
Aaron Klotz
Mirko Brodesser
Noemi Erli
Boris Zbarsky
Brendan Dahl
harry
Brindusan Cristian
Sylvestre Ledru
Sebastian Hengst
Alexander Surkov
Victor Porof
L. David Baron
Maliha Islam
Cameron McCormack
Eitan Isaacson
Csoregi Natalia
Narcis Beleuzu
Andrew Swan
Ciure Andrei
Jonathan Kingston
Andreea Pavel
Joanmarie Diggs