This patch is similar to part 4 but for Android a11y.
Conversions over to `NativeWeakPtr` are pretty straight forward thanks to the
type system. Basically we take a `NativeWeakPtr`, call `Access()` on it, and
if the accessor is truthy, then we call whatever methods we need to call.
Creation of new pointers is done using `NativeWeakPtrHolder::Attach()` and
detaching of strong references is done by `NativeWeakPtr::Detach()`.
Differential Revision: https://phabricator.services.mozilla.com/D87365
We need a sync IPC call for this because otherwise the number of smaller sync messages we would need to call would be variable.
Differential Revision: https://phabricator.services.mozilla.com/D88076
The new pivot boundaries might consist of accessibles that don't exist
yet in the parent process proxy tree.
I guess we can tweak the timing of the pivot boundaries message to be
sent only after remote tree construction. But this seems like an edge
case that quickly gets corrected after the next cache refresh.
Differential Revision: https://phabricator.services.mozilla.com/D85912
DynamicIA2Data can be built to be transmitted in two different ways:
1. As part of the payload included in the stream when an accessible is marshaled; or
2. As an out parameter returned by IGeckoBackChannel::Refresh().
DynamicIA2Data includes arrays for row/column header ids.
Normally, such arrays would be allocated by CoTaskMemAlloc and freed by CoTaskMemFree.
However, in the first case, the struct is actually marshaled by RPC encoding functions, not by COM itself.
This means we must use midl_user_allocate/free, lest we crash.
We previously used midl_user_allocate/free for the second case as well.
Unfortunately, it turns out that this too causes crashes.
To fix this, we now use different memory allocation functions depending on how the struct is transmitted.
This patch also cleans up the old DynamicIA2Data in the client before calling IGeckoBackChannel::Refresh.
Previously, we didn't do this, which would have resulted in a leak.
Differential Revision: https://phabricator.services.mozilla.com/D82823
This is already handled in a different way on Windows.
For documents at the top level of their process (including OOP iframes), we can just set the flag rather than waiting for a message, since we can never get queries for such documents or descendants before parent process construction is complete.
Differential Revision: https://phabricator.services.mozilla.com/D81009
This includes 3 changes:
1. Add a lazy ranges getter to AccTextSelChangeEvent.
2. Create an XPCOM interface for testing purposes.
3. Add IPDL bindings for passing ranges in e10s.
Differential Revision: https://phabricator.services.mozilla.com/D80556
We can receive IPC events after a DocAccessibleParent is shut down if the BrowserParent is in the process of being destroyed (probably the tab closed) but there are still events in the IPC queue.
Most Recv*Event methods in BrowserParent check mShutdown, but a few don't.
For the events that don't, if the event is for a document, we'll successfully fire the platform event, and then successfully get and cache an xpcAccessibleDocument.
However, that xpcAccessibleDocument will never be removed from the cache because it's already shut down, so NotifyOfRemoteDocShutdown (which would normally remove it from the XPC cache) won't get called.
This results in a leaked object.
Thus, it's important that all Recv*Event methods drop the event if mShutdown is true.
This patch adds that check to the methods which didn't have it already.
Differential Revision: https://phabricator.services.mozilla.com/D79780
Otherwise, if we're replacing a previous top level doc, we might refer to the old top level doc during initialization.
Differential Revision: https://phabricator.services.mozilla.com/D79398
When window emulation is enabled, the emulated window is set on the top level DocAccessibleChild.
However, it isn't set on child documents (in-process iframes).
Therefore, when querying the window handle, we need to check for an emulated window handle on the top level document and return that if present.
This fixes the window handle returned by IAccessible2::get_windowHandle.
Note that the window handle used when firing events was already correct, as that is determined in the parent process.
In the parent process, the emulated window was already being propagated down to child DocAccessibleParents by BrowserParent::RecvPDocAccessibleConstructor.
Differential Revision: https://phabricator.services.mozilla.com/D79035
1. When we unmarshal a row/column header, cache it so we can get it by id later.
2. get_rowHeaderCells and get_columnHeaderCells use the header ids in the payload.
If the headers are in the cache (as per 1), return them to the client.
Otherwise, fall back to a cross-process call, which might happen if we haven't encountered the header yet.
Differential Revision: https://phabricator.services.mozilla.com/D76667
1. When we unmarshal a row/column header, cache it so we can get it by id later.
2. get_rowHeaderCells and get_columnHeaderCells use the header ids in the payload.
If the headers are in the cache (as per 1), return them to the client.
Otherwise, fall back to a cross-process call, which might happen if we haven't encountered the header yet.
Differential Revision: https://phabricator.services.mozilla.com/D76667
DocAccessibleParent::AddChildDoc sends a COM proxy for the embedded document to the embedder process hosting the iframe.
This gets returned as the child of the embedder OuterDocAccessible.
Whenever we send a proxy to a content process, we must hold a PreservedStreamPtr in the parent process.
Previously, we set mDocProxyStream on the parent (embedder) document.
However, if a document had multiple OOP iframes, this meant we ended up losing the PreservedStreamPtr for all but the last added child OOP document.
We now set mDocProxyStream on the child document instead, since there can only be one embedder OuterDocAccessible per child document.
Differential Revision: https://phabricator.services.mozilla.com/D74584
1. CleanupStaticIA2Data just called ReleaseStaticIA2DataInterfaces and zeroed memory.
We don't need it to zero memory, since we're going to delete the data anyway.
So, just call ReleaseStaticIA2DataInterfaces directly and get rid of CleanupStaticIA2Data.
2. CleanupDynamicIA2Data had a aZeroMemory argument, but no caller ever set it to true.
Therefore, get rid of the argument.
Differential Revision: https://phabricator.services.mozilla.com/D70297
This avoids separate cross-thread calls when marshaling each object returned from an IGeckoBackChannel bulk fetch method.
Differential Revision: https://phabricator.services.mozilla.com/D69485
For OOP iframes, the top level document lives in a different process.
Previously, we incorrectly returned the top level document in the same process.
This was causing JAWS to incorrectly identify OOP iframe documents as separate tab documents.
To fix this, we must send the real top level document down from the parent process and return that when requested in the content process.
Differential Revision: https://phabricator.services.mozilla.com/D70162
--HG--
extra : moz-landing-system : lando
This wasn't useful cross-platform.
ATK was the only consumer of this and it now uses ProxyAccessible::ChildAtPoint.
This also means the related aNeedsScreenCoords functionality in PDocAccessible::AccessibleAtPoint is no longer needed and has thus been removed.
Finally, this renames PDocAccessible::AccessibleAtPoint to PDocAccessible::ChildAtPoint for consistency with Accessible::ChildAtPoint now that the functionality is mirrored.
Differential Revision: https://phabricator.services.mozilla.com/D67987
--HG--
extra : moz-landing-system : lando
When we hit an OOP iframe, we must walk into the child document and continue the search from there.
Differential Revision: https://phabricator.services.mozilla.com/D66711
--HG--
extra : moz-landing-system : lando
Accessible::ChildAtPoint can return an Accessible in a descendant document.
Thus, we must return the result PDocAccessible via IPC, not just the id.
Previously, we only returned the id, but we'd fail when we tried to look it up if it belonged to a descendant document.
Differential Revision: https://phabricator.services.mozilla.com/D66710
--HG--
extra : moz-landing-system : lando
This code (and an upcoming dependent patch) is currently behind a pref which is disabled by default, as there is uncertainty as to how it might impact the Dev Tools A11y Panel.
The A11y Panel is currently a moving target due to ongoing refactor for Fission.
This pref should be removed once that groundwork is complete and the impact has been verified.
This patch also includes fixes to some ProxyAccessible methods which previously crashed when there was no parent, as is the case for top level documents.
Without these fixes, the Dev Tools A11y Panel would crash the parent process.
Differential Revision: https://phabricator.services.mozilla.com/D66354
--HG--
extra : moz-landing-system : lando
We were using the wrong Accessible method to get the level. We also need to swap IPDL methods to use the right one.
Differential Revision: https://phabricator.services.mozilla.com/D65645
--HG--
extra : moz-landing-system : lando
When window emulation is enabled, each tab document gets its own HWND.
OOP iframes get the same HWND as their tab document and fire events with that HWND.
However, the root accessible for the HWND (the tab document) can't return accessibles for OOP iframes.
Therefore, we must get the root accessible from the main HWND and call accChild on that instead.
We must do this in the parent process, but the tab document accessible is in the content process.
Although OOP a11y clients talk directly to the content process, the clients that need window emulation are in-process.
All in-process client calls get intercepted by AccessibleHandler, so we can deal with this forwarding in AccessibleHandler.
Differential Revision: https://phabricator.services.mozilla.com/D65054
--HG--
extra : moz-landing-system : lando
Windows programs run via Wine don't like Unix absolute paths (they look
like command line arguments), so we need to use relative paths.
Mingw already run fxc2 via wine, but for some reason it doesn't care
about the Unix absolute paths. genshaders does need some adjustements to
run properly with the real fxc.
Now, on actual Windows, because the temporary directory where
tempfile.NamedTemporaryFile creates files by default is not necessarily
on the same drive as where the command runs from, a relative path can't
be constructed. So we also force the temporary file to be created in the
current (obj) directory.
There is no similar concern for other files because we only go from
objdir to srcdir, and the build system already doesn't support both
being on a separate drive.
While here, flush stdout when the genshared script writes to it, so that
the messages are printed out immediately rather than randomly, later,
after output from subprocesses.
Differential Revision: https://phabricator.services.mozilla.com/D64294
--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
This allows `performAction` to immediately return false if a boundary is
reached and allow TalkBack to navigate past the web view.
Change viewport cache listener to reorder since it should catch all tree
mutations in the document.
Differential Revision: https://phabricator.services.mozilla.com/D63117
--HG--
extra : moz-landing-system : lando
This was done by:
This was done by applying:
```
diff --git a/python/mozbuild/mozbuild/code-analysis/mach_commands.py b/python/mozbuild/mozbuild/code-analysis/mach_commands.py
index 789affde7bbf..fe33c4c7d4d1 100644
--- a/python/mozbuild/mozbuild/code-analysis/mach_commands.py
+++ b/python/mozbuild/mozbuild/code-analysis/mach_commands.py
@@ -2007,7 +2007,7 @@ class StaticAnalysis(MachCommandBase):
from subprocess import Popen, PIPE, check_output, CalledProcessError
diff_process = Popen(self._get_clang_format_diff_command(commit), stdout=PIPE)
- args = [sys.executable, clang_format_diff, "-p1", "-binary=%s" % clang_format]
+ args = [sys.executable, clang_format_diff, "-p1", "-binary=%s" % clang_format, '-sort-includes']
if not output_file:
args.append("-i")
```
Then running `./mach clang-format -c <commit-hash>`
Then undoing that patch.
Then running check_spidermonkey_style.py --fixup
Then running `./mach clang-format`
I had to fix four things:
* I needed to move <utility> back down in GuardObjects.h because I was hitting
obscure problems with our system include wrappers like this:
0:03.94 /usr/include/stdlib.h:550:14: error: exception specification in declaration does not match previous declaration
0:03.94 extern void *realloc (void *__ptr, size_t __size)
0:03.94 ^
0:03.94 /home/emilio/src/moz/gecko-2/obj-debug/dist/include/malloc_decls.h:53:1: note: previous declaration is here
0:03.94 MALLOC_DECL(realloc, void*, void*, size_t)
0:03.94 ^
0:03.94 /home/emilio/src/moz/gecko-2/obj-debug/dist/include/mozilla/mozalloc.h:22:32: note: expanded from macro 'MALLOC_DECL'
0:03.94 MOZ_MEMORY_API return_type name##_impl(__VA_ARGS__);
0:03.94 ^
0:03.94 <scratch space>:178:1: note: expanded from here
0:03.94 realloc_impl
0:03.94 ^
0:03.94 /home/emilio/src/moz/gecko-2/obj-debug/dist/include/mozmemory_wrap.h:142:41: note: expanded from macro 'realloc_impl'
0:03.94 #define realloc_impl mozmem_malloc_impl(realloc)
Which I really didn't feel like digging into.
* I had to restore the order of TrustOverrideUtils.h and related files in nss
because the .inc files depend on TrustOverrideUtils.h being included earlier.
* I had to add a missing include to RollingNumber.h
* Also had to partially restore include order in JsepSessionImpl.cpp to avoid
some -WError issues due to some static inline functions being defined in a
header but not used in the rest of the compilation unit.
Differential Revision: https://phabricator.services.mozilla.com/D60327
--HG--
extra : moz-landing-system : lando
rg -l 'mozilla/Move.h' | xargs sed -i 's/#include "mozilla\/Move.h"/#include <utility>/g'
Further manual fixups and cleanups to the include order incoming.
Differential Revision: https://phabricator.services.mozilla.com/D60323
--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
1. Implement ProxyAccessible::TakeFocus on Windows.
2. Use this implementation in xpcAccessible::TakeFocus like we do on other platforms.
3. Enable accessible/tests/browser/fission/browser_take_focus.js on Windows, since it now works.
Differential Revision: https://phabricator.services.mozilla.com/D59977
--HG--
extra : moz-landing-system : lando
This is an alternative to carrying a revert of the offending changeset, since the bug doesn't show hope of a fix anytime soon, or maybe ever. This way we don't have to keep rebasing the patch as we pick up new clangs, and developers don't have to remember to apply the patch when building a local compiler.
Differential Revision: https://phabricator.services.mozilla.com/D59200
--HG--
extra : moz-landing-system : lando
For paragraphs, divs, spans, etc., a11y focus on Android goes to text leaf Accessibles, rather than to the HyperTextAccessible container.
This does make sense, as these containers frequently embed other content, so the text needs to be reachable as a separate item.
However, previously, performing text navigation on these text leaf Accessibles returned the HyperTextAccessible parent.
This isn't supported by Talkback, and even if it were, it causes other problems; e.g. a11y focus being lost if the user was focused on a child other than the first child of such a container.
Therefore, if text navigation was performed on a text leaf Accessible, we now return a result within the text leaf Accessible if possible, rather than the HyperTextAccessible.
1. Make AccessibleWrap::GetTextContents support text leaf Accessibles (for both local and remote proxied Accessibles).
This is used when providing text for text traversal events.
2. When navigating text on Android, we use Pivot::Next/PrevText.
However, this will always return a HyperTextAccessible, even when starting on a text leaf.
Therefore, if the result from Pivot::Next/prevText resides entirely within the same text leaf, translate the offsets from the HyperTextAccessible so they're relative to the text leaf and return the text leaf.
3. Pivot::Next/PrevText already supported starting from a text leaf Accessible.
However, they ignored the offsets, which meant that navigating from a text leaf would always navigate to the start/end of the text leaf.
Now, if a text leaf is passed to Pivot::Next/PrevText, the offsets (if specified) are translated to the HyperTextAccessible parent first.
4. Adjust the existing character/word/line tests so they ensure that navigation returns the node that has a11y focus; i.e. the text leaf.
Differential Revision: https://phabricator.services.mozilla.com/D57269
--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
The change to moz.build unveiled a couple unified build issues that I also had
to fix.
Depends on D55365
Differential Revision: https://phabricator.services.mozilla.com/D55366
--HG--
extra : moz-landing-system : lando
1. When creating a DocAccessibleParent for an embedded document in an OOP iframe, it's possible that the embedder accessible hasn't been set yet.
This can occur if the iframe is initially hidden.
Previously, we incorrectly set the document up as a top level document (e.g. tab document) in this case.
Now, we set up the document as top level in its content process, set up the proxy, etc.
The document will be added to its child document later when the embedder is set.
2. When setting the embedder accessible for an OOP iframe, check if the embedded DocAccessibleParent already exists.
This can happen if an iframe is hidden and then shown or an iframe is reflowed by layout.
If it already exists, add the embedded (child) document to its embedder.
3. Mac's implementation of ProxyCreated requires that AddChildDoc be called *before* ProxyCreated so it can invalidate the native children of the parent.
Because it's possible for an OOP iframe document to be added to its embedder after the document is created, we can't satisfy this requirement for OOP iframe documents.
Therefore, we now allow a null parent in Mac's ProxyCreated and use the reorder event fired later to invalidate the native children.
Differential Revision: https://phabricator.services.mozilla.com/D51357
--HG--
extra : moz-landing-system : lando
1. When creating a DocAccessibleParent for an embedded document in an OOP iframe, it's possible that the embedder accessible hasn't been set yet.
This can occur if the iframe is initially hidden.
Previously, we incorrectly set the document up as a top level document (e.g. tab document) in this case.
Now, we set up the document as top level in its content process, set up the proxy, etc.
The document will be added to its child document later when the embedder is set.
2. When setting the embedder accessible for an OOP iframe, check if the embedded DocAccessibleParent already exists.
This can happen if an iframe is hidden and then shown or an iframe is reflowed by layout.
If it already exists, add the embedded (child) document to its embedder.
Differential Revision: https://phabricator.services.mozilla.com/D51357
--HG--
extra : moz-landing-system : lando
1. When creating a DocAccessibleParent for an embedded document in an OOP iframe, it's possible that the embedder accessible hasn't been set yet.
This can occur if the iframe is initially hidden.
Previously, we incorrectly set the document up as a top level document (e.g. tab document) in this case.
Now, we set up the document as top level in its content process, set up the proxy, etc.
The document will be added to its child document later when the embedder is set.
2. When setting the embedder accessible for an OOP iframe, check if the embedded DocAccessibleParent already exists.
This can happen if an iframe is hidden and then shown or an iframe is reflowed by layout.
If it already exists, add the embedded (child) document to its embedder.
Differential Revision: https://phabricator.services.mozilla.com/D51357
--HG--
extra : moz-landing-system : lando
Please note that it is the first reformat with clang-format 9
I only saw a fix in the .mm file
# ignore-this-changeset
Differential Revision: https://phabricator.services.mozilla.com/D49056
--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 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
Having a full VPATH for the srcdir sometimes causes make to grab the
wrong prerequisite for a rule, in particular if we have a file in the
srcdir and also generate a file of the same name in the objdir. We don't
really need VPATH anymore though, since most of the information comes
from mozbuild, where we can explicitly list the path to the srcdir or
objdir as necessary.
Differential Revision: https://phabricator.services.mozilla.com/D42968
--HG--
extra : moz-landing-system : lando
For OOP iframes, sometimes, AddChildDoc gets called before the embedder sends us the OuterDocAccessible.
Previously, we crashed when this occurred.
Now, we add the child when the OuterDocAccessible proxy gets created later.
Differential Revision: https://phabricator.services.mozilla.com/D42798
--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
Previously, we expected that we'd always be able to get the COM proxy for the parent (outer doc), so we crashed if it was null.
For an out-of-process iframe, this sometimes fails.
That is probably because the outer doc died in the embedder process, but the parent process hasn't received a message to remove it from the ProxyAccessible tree yet.
Differential Revision: https://phabricator.services.mozilla.com/D40150
--HG--
extra : moz-landing-system : lando
Narcis Beleuzu
Aaron Klotz
Mike Hommey
Eitan Isaacson
Simon Giesecke
Noemi Erli
James Teh
Sylvestre Ledru
Jonathan Watt
Yura Zenevich
Chris Peterson
Dorel Luca
Morgan Reschenberg
Emilio Cobos Álvarez
David Major
Gabriele Svelto
Cosmin Sabou
Ciure Andrei
Ricky Stewart
Daniel Varga
Mike Shal
Christian Holler