JAWS apparently does this sometimes.
In particular, this was causing a crash when we tried to check the UIA pref because that pref can only be accessed from the main thread.
Differential Revision: https://phabricator.services.mozilla.com/D210417
UIA doesn't have a native property to expose aria-atomic, so we need to expose this via AriaProperties.
If it's not exposed, Narrator will assume true, so we must expose it even if it's not explicitly present.
As part of this, I removed the local-only implementation of AriaProperties.
While it was more complete, it's not useful to have this supported only for LocalAccessible.
In addition, it didn't expose implicit default values, which this atomic case proves we need in some cases.
We'll add more properties as needed.
Differential Revision: https://phabricator.services.mozilla.com/D209659
Previously, we didn't expose AriaRole at all if there was no explicit ARIA role (as specified by the role attribute).
However, there are quite a few ARIA roles where the UIA control type and other properties don't expose sufficient semantics alone.
Exposing AriaRole in these cases allows clients to perceive these semantics if they wish.
Differential Revision: https://phabricator.services.mozilla.com/D208973
This will be used to implement the Table and TableItem patterns, but will also be useful for other patterns implemented in future.
Differential Revision: https://phabricator.services.mozilla.com/D208276
Note that even though UIA has a dedicated HeadingLevel property, Chromium doesn't implement it and the documentation says the Level property can be used for headings as well.
Differential Revision: https://phabricator.services.mozilla.com/D207399
Per the IDL, this method returns enum ProviderOptions.
Strictly speaking, that's not correct because this is actually a bit field combining values from the enum, rather than returning only a single value from the enum.
It seems some compilers are more strict about this and thus fail with an error like: assigning to 'enum ProviderOptions' from incompatible type 'int'
To work around this, static_cast the value before returning it.
Differential Revision: https://phabricator.services.mozilla.com/D205667
Aside from being a fundamental part of semantics, this is needed for our tests.
These mappings are based on the Core AAM and HTML AAM specs, plus some personal judgement where Gecko roles weren't covered by these specs.
UIA control types are rather limited and they apparently expect us to expose a lot of things using LocalizedControlType, but that isn't implemented for now.
I expect these will need to be revised in future, but this is a starting point.
Differential Revision: https://phabricator.services.mozilla.com/D205185
This identifies the root of our implementation and allows for focus querying and hit testing.
We also implement IRawElementProviderSimple::get_HostRawElementProvider to connect to UIA's HWND provider.
Differential Revision: https://phabricator.services.mozilla.com/D205182
Our IUnknownImpl macros avoid boilerplate, but they weren't designed to handle the quirky inheritance of our MSAA/UIA implementation.
Among other things, using these macros required us to override AddRef and Release in uiaRawElmProvider, which was a bit confusing.
Rather than perpetuating this weirdness as things get more complex, just implement what we need by hand.
Differential Revision: https://phabricator.services.mozilla.com/D205180
1. Respond to WM_GETOBJECT with our IRawElementProviderSimple implementation for the root Accessible of the HWND.
2. Don't allow QueryInterface to UIA interfaces if the UIA pref is disabled. This stops WM_GETOBJECT from returning our UIA implementation in this case.
3. Specify the appropriate provider options.
Differential Revision: https://phabricator.services.mozilla.com/D205179
This is not ideal, because they fall back to position the popup under
the cursor, but it's probably better.
The right thing to do would be for Windows to use the TITLEBARINFOEX
message. We should probably still land that code just so they can
eventually use it, seems worth doing anyways.
Differential Revision: https://phabricator.services.mozilla.com/D203423
Exactly what should be a control element on the web and what shouldn't isn't really documented anywhere.
So, this is a little based on ideas from Chromium and a little based on my own understanding of how this should ideally work.
This will definitely need to be tweaked as we further develop UIA.
For now, the primary aim is to avoid the performance cliff caused by the UIA -> IA2 proxy's suboptimal implementation of IsControlElement.
We map IsContentElement to IsControlElement, just as Chromium does.
Differential Revision: https://phabricator.services.mozilla.com/D202923
This changes comes with several different refactorings all rolled into one,
unfotunately I couldn't find a way to pull them apart:
- First of all annotations now can either recorded (that is, we copy the value
and have the crash reporting code own the copy) or registered. Several
annotations are changed to use this functionality so that we don't need to
update them as their value change.
- The code in the exception handler is modified to read the annotations from
the mozannotation_client crate. This has the unfortunate side-effect that
we need three different bits of code to serialize them: one for annotations
read from a child process, one for reading annotations from the main process
outside of the exception handler and one for reading annotations from the
main process within the exception handler. As we move to fully
out-of-process crash reporting the last two methods will go away.
- The mozannotation_client crate now doesn't record annotation types anymore.
I realized as I was working on this that storing types at runtime has two
issues: the first one is that buggy code might change the type of an
annotation (that is record it under two different types at two different
moments), the second issue is that types might become corrupt during a
crash, so better enforce them at annotation-writing time. The end result is
that the mozannotation_* crates now only store byte buffers, track the
format the data is stored in (null-terminated string, fixed size buffer,
etc...) but not the type of data each annotation is supposed to contain.
- Which brings us to the next change: concrete types for annotations are now
enforced when they're written out. If an annotation doesn't match the
expected type it's skipped. Storing an annotation with the wrong type will
also trigger an assertion in debug builds.
Differential Revision: https://phabricator.services.mozilla.com/D195248
KeyboardShortcut is only implemented for LocalAccessible because KeyboardShortcut isn't currently relevant (or supported) for RemoteAccessible.
AriaProperties can't be supported for RemoteAccessible currently.
See the code comment for details.
Differential Revision: https://phabricator.services.mozilla.com/D202551
