`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
If window emulation is enabled, an out-of-process iframe document should use the same emulated window as its embedder.
Previously, we were setting this on DocAccessibleParent, but we weren't sending it to content to make it available on DocAccessibleChild.
This meant that accessibles in out-of-process iframe documents were reporting the wrong window handle.
Differential Revision: https://phabricator.services.mozilla.com/D32788
--HG--
extra : moz-landing-system : lando
It must be possible to retrieve any accessible by calling IAccessible::accChild on the RootAccessible (in the parent process) with the unique id of the desired accessible.
Among other things, this is the way accessibility events are targeted on Windows.
Previously, this code only searched remote documents at the top level of the tree.
In order to support out-of-process iframes, it must now also search embedded documents at the top level of their content process.
As part of this, the MSAA id must be set for out-of-process iframe documents, just as it is for top level documents.
This was already being sent from the content process, but previously, we didn't store this in the parent process.
Differential Revision: https://phabricator.services.mozilla.com/D32417
--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
Previously, a COM proxy was only sent from content for top level documents.
Now, a COM proxy is also sent (and needed) for out-of-process iframe documents.
This change adjusts GetProxiedAccessibleInSubtree accordingly.
Differential Revision: https://phabricator.services.mozilla.com/D32283
--HG--
extra : moz-landing-system : lando
DocAccessibleParent already has IsTopLevel(), which identifies a document at the top level of the hierarchy; i.e. it has no parents.
Now that we have out-of-process iframes, we need to be able to identify and retrieve documents at the top level of their content process, even if they are embedded by another remote document.
DocAccessibleParent::IsTopLevelInContentProcess() has been introduced to achieve this.
BrowserParent::GetTopLevelDocAccessible() now uses this instead of IsTopLevel(), since we want to be able to get the top DocAccessibleParent even for a BrowserParent for an out-of-process iframe.
Differential Revision: https://phabricator.services.mozilla.com/D32282
--HG--
extra : moz-landing-system : lando
I think this is a good change regardless of other discussion in bug 1552587. If
we decide to move `mColor` to the top-level of the struct that can be done
separately.
Differential Revision: https://phabricator.services.mozilla.com/D32726
--HG--
extra : moz-landing-system : lando
It must be possible to retrieve any accessible by calling IAccessible::accChild on the RootAccessible (in the parent process) with the unique id of the desired accessible.
Among other things, this is the way accessibility events are targeted on Windows.
Previously, this code only searched remote documents at the top level of the tree.
In order to support out-of-process iframes, it must now also search embedded documents at the top level of their content process.
As part of this, the MSAA id must be set for out-of-process iframe documents, just as it is for top level documents.
This was already being sent from the content process, but previously, we didn't store this in the parent process.
Differential Revision: https://phabricator.services.mozilla.com/D32417
--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
Previously, a COM proxy was only sent from content for top level documents.
Now, a COM proxy is also sent (and needed) for out-of-process iframe documents.
This change adjusts GetProxiedAccessibleInSubtree accordingly.
Differential Revision: https://phabricator.services.mozilla.com/D32283
--HG--
extra : moz-landing-system : lando
DocAccessibleParent already has IsTopLevel(), which identifies a document at the top level of the hierarchy; i.e. it has no parents.
Now that we have out-of-process iframes, we need to be able to identify and retrieve documents at the top level of their content process, even if they are embedded by another remote document.
DocAccessibleParent::IsTopLevelInContentProcess() has been introduced to achieve this.
BrowserParent::GetTopLevelDocAccessible() now uses this instead of IsTopLevel(), since we want to be able to get the top DocAccessibleParent even for a BrowserParent for an out-of-process iframe.
Differential Revision: https://phabricator.services.mozilla.com/D32282
--HG--
extra : moz-landing-system : lando
Windows accessibility clients talk directly to the content process via COM.
In order to expose an OOP iframe document accessible as a child of the embedder iframe accessible via COM, the embedder process needs a COM proxy for the iframe document accessible.
This is exposed on the embedder's BrowserBridgeChild, so we can use this when a client asks for the child of the OuterDocAccessible.
Differential Revision: https://phabricator.services.mozilla.com/D32281
--HG--
extra : moz-landing-system : lando
For an out-of-process iframe, we need to be able to return a remote embedder accessible as a child of an OuterDocAccessible.
For parent process OuterDocAccessibles, we use the ProxyAccessible for the embedded document.
In the case of out-of-process iframes, there is no ProxyAccessible for the embedded document, since the iframe is in a content process and ProxyAccessibles only exist in the parent process.
Like ProxyAccessibleWrap, the only real method that gets called is GetNativeInterface, which returns a COM proxy for the document.
Differential Revision: https://phabricator.services.mozilla.com/D32278
--HG--
extra : moz-landing-system : lando
PresShell::EventHandler::HandleEventWithCurrentEventInfo is the only possible
place will do such handling; other places pass either a nullptr or a
non-MouseDown/Up event.
Differential Revision: https://phabricator.services.mozilla.com/D32431
--HG--
extra : moz-landing-system : lando
For iframes in a different process to their embedder, when the embedded iframe content process tells the parent process about the iframe document, it does not have the actor for the parent document accessible, nor does it know the accessible id of the embedding iframe.
However, the embedder will have previously sendt the actor and id for the embedder accessible to the parent via PBrowserBridge, so we can use that to identify the parent accessible.
Differential Revision: https://phabricator.services.mozilla.com/D31395
--HG--
extra : moz-landing-system : lando
We do this when the OuterDocAccessible is constructed.
This will be used later in the parent process to link the trees together when the iframe's embedded document accessible is added.
Differential Revision: https://phabricator.services.mozilla.com/D31394
--HG--
extra : moz-landing-system : lando
Supporting out-of-process iframes requires us to hold onto a DocAccessibleParent in BrowserBridgeParent.
However, we can't guarantee the order of cleanup between the two content processes.
Therefore, we need reference counting to kee the object alive.
Differential Revision: https://phabricator.services.mozilla.com/D32277
--HG--
extra : moz-landing-system : lando
