This will contain methods that can be used for both local and remote Accessibles.
It is inherited into both HyperTextAccessible (local) and RemoteAccessibleBase.
Differential Revision: https://phabricator.services.mozilla.com/D127206
The implementation for RemoteAccessibleBase is just a stub; we don't cache the caret yet.
However, this needs to be in HyperTextAccessibleBase because it is used by ConvertMagicOffset, which will be moved in an upcoming patch.
Differential Revision: https://phabricator.services.mozilla.com/D127209
Although HyperTextAccessibleBase implements these, we leave the HyperTextAccessible implementations (overriding the base) because they do caching.
Depending on performance, we may eventually want to move the caching into the base implementation.
I decided not to do this initially because it will use extra memory in the parent process and it may be a premature optimisation.
Differential Revision: https://phabricator.services.mozilla.com/D127207
This will contain methods that can be used for both local and remote Accessibles.
It is inherited into both HyperTextAccessible (local) and RemoteAccessibleBase.
Differential Revision: https://phabricator.services.mozilla.com/D127206
As part of this, we no longer cache the name for text accessibles, as that would be redundant.
Instead, we return the cached text in RemoteAccessible::Name.
Differential Revision: https://phabricator.services.mozilla.com/D127202
Changed the array type to nsTArray to avoid copies and get compile-time
errors if we ever try to do that. To set an array as a value, it must be
moved.
Differential Revision: https://phabricator.services.mozilla.com/D125899
Changed the array type to nsTArray to avoid copies and get compile-time
errors if we ever try to do that. To set an array as a value, it must be
moved.
Differential Revision: https://phabricator.services.mozilla.com/D125899
This allows us to support 255 content processes instead of 127.
It also means we have 1 less bit for the Accessible portion of the id, which means we can support less Accessibles per process.
Hopefully, this shouldn't be a problem, especially with Fission generally meaning less documents per process.
Differential Revision: https://phabricator.services.mozilla.com/D104344
There can be a scenario where an initial cache is pushed to an accessible via an update and not an "initial" push that a doc load or a subtree show would give.
For example, an accessible might not have a name, description, or numeric value (that is all we currently cache), but then get a name later in its lifetime. If that is the case the accessible will get a cache AccAttributes with a DeleteEntry value for "description" since its description is still empty. That entry should not be stored in the cache.
Differential Revision: https://phabricator.services.mozilla.com/D124484
When constructing the initial cache, don't push empty or default fields.
Also, have a way to remove fields from an established cache if it
becomes empty/default.
Differential Revision: https://phabricator.services.mozilla.com/D124127
Eventually we will want to add the Name method as an abstract method in
Accessible and implemented it platform-independent in
RemoteAccessibleBase.
Differential Revision: https://phabricator.services.mozilla.com/D121925
This is a good place to formalize the following naming convention:
* A "field" is and direct accessible getter method (name,
role, value, min, max, etc.)
* An "attribute" is a member of the "attributes" field.
With that said, I think AccAttributes should probably be named
AccProperties or something of the sort. Might leave that for another
time.
Differential Revision: https://phabricator.services.mozilla.com/D121924
This will allow us to use the list of accessibles to be serialized later
for pushing a cache. The single array also gives us an opportunity to
paginate the cache, if needed.
Differential Revision: https://phabricator.services.mozilla.com/D121923
As part of this, I changed RemoteAccessible::RemoteChildAt (and thus RemoteAccessible::ChildAt) so it doesn't crash when passed an invalid child index.
Our EnumVariant implementation relied on this with LocalChildAt.
I think it makes sense for LocalChildAt, RemoteChildAt and ChildAt to be consistent in this regard.
Differential Revision: https://phabricator.services.mozilla.com/D122681
If an iframe is hidden, its OuterDocAccessible will be destroyed, but the PBrowserBridge still exists.
Since the OuterDocAccessible was destroyed, its id can be reused.
Therefore, if a new embedder accessible hasn't already been set, clear the embedder accessible on PBrowserBridge.
This ensures that the wrong accessible can't accidentally be used when an OOP iframe document is added while the iframe is hidden.
Differential Revision: https://phabricator.services.mozilla.com/D121015
Allow for downstream projects such as Thunderbird to set different GUIDs for
AccessibleHandler to avoid clashes when both applications are installed.
The GUIDs themselves can be defined in confvars.sh or in branding/configure.sh
depending on the specific needs of the application. Fallback GUIDs are in
old-configure.
Differential Revision: https://phabricator.services.mozilla.com/D118124
Previously, when the cache was disabled, we had a RemoteAccessibleWrap for every RemoteAccessible.
This is no longer necessary and now only serves as an extra level of indirection and memory waste.
We still keep the stub MsaaAccessible to hold the id sent up from content.
Differential Revision: https://phabricator.services.mozilla.com/D117528
This implements Jamie's suggested fixes for a screenreader issue when the
skeleton UI is enabled. Most of the work here is just pulling out pieces from the
files we needed to include in mozglue so that any references to, say, nsString
or other pieces from libxul either no longer exist or are only included when
building libxul. In a few cases this meant creating whole files to house single
functions, which isn't so pretty, but it was the best I could come up with to
get the job done.
Differential Revision: https://phabricator.services.mozilla.com/D117663
This implements Jamie's suggested fixes for a screenreader issue when the
skeleton UI is enabled. Most of the work here is just pulling out pieces from the
files we needed to include in mozglue so that any references to, say, nsString
or other pieces from libxul either no longer exist or are only included when
building libxul. In a few cases this meant creating whole files to house single
functions, which isn't so pretty, but it was the best I could come up with to
get the job done.
Differential Revision: https://phabricator.services.mozilla.com/D117663
This implements Jamie's suggested fixes for a screenreader issue when the
skeleton UI is enabled. Most of the work here is just pulling out pieces from the
files we needed to include in mozglue so that any references to, say, nsString
or other pieces from libxul either no longer exist or are only included when
building libxul. In a few cases this meant creating whole files to house single
functions, which isn't so pretty, but it was the best I could come up with to
get the job done.
Differential Revision: https://phabricator.services.mozilla.com/D117663
An OuterDocAccessible can be recreated, causing the embedder accessible for a BrowserBridgeParent (OOP iframe) to change.
However, changing the src of an iframe can also cause a new BrowserBridgeParent to be created.
Previously, if addition of the child document was still pending when this occurred (because the OuterDocAccessible hadn't been sent to the parent yet), this pending addition could remain, causing problems if the id was reused later.
To fix this (and to hopefully make this more robust given the continued problems we're seeing in the wild with this area of the code), I've completely refactored the way we handle these pending child doc additions.
Rather than tracking the pending additions by their accessible id and child doc, we track them by their BrowserBridgeParent.
This way, we're closest to a single source of truth.
We also remove a pending addition when an associated BrowserBridgeParent is destroyed.
Differential Revision: https://phabricator.services.mozilla.com/D117889
An OuterDocAccessible can be recreated, causing the embedder accessible for a BrowserBridgeParent (OOP iframe) to change.
However, changing the src of an iframe can also cause a new BrowserBridgeParent to be created.
Previously, if addition of the child document was still pending when this occurred (because the OuterDocAccessible hadn't been sent to the parent yet), this pending addition could remain, causing problems if the id was reused later.
To fix this (and to hopefully make this more robust given the continued problems we're seeing in the wild with this area of the code), I've completely refactored the way we handle these pending child doc additions.
Rather than tracking the pending additions by their accessible id and child doc, we track them by their BrowserBridgeParent.
This way, we're closest to a single source of truth.
We also remove a pending addition when an associated BrowserBridgeParent is destroyed.
Differential Revision: https://phabricator.services.mozilla.com/D117889
James Teh
Cristian Tuns
Morgan Reschenberg
Butkovits Atila
Eitan Isaacson
criss
Marian-Vasile Laza
Andi-Bogdan Postelnicu
Ryan VanderMeulen
Rob Lemley
Kashav Madan
Doug Thayer
Narcis Beleuzu
Dorel Luca