We have RemoteAccessible::mParent and RemoteAccessible::mDoc, so DocAccessibleParent::mParentDoc was redundant.
Aside from the redundancy, this was one extra thing we needed to keep up to date and reason about.
This involved changing the call to RemoveChildDoc in Destroy to use Unbind instead because Unbind clears the parent RemoteAccessible, but RemoveChildDoc didn't.
That meant we had a dangling RemoteAccessible::mParent pointer, which was always a problem, but is more problematic now that we no longer have mParentDoc and the destructor checks the parent document.
Since Unbind is the only caller of RemoveChildDoc, RemoveChildDoc has been merged into Unbind.
This means there is now only a single place where child documents are unbound from their parent, which should make things easier to reason about.
Differential Revision: https://phabricator.services.mozilla.com/D218802
While an id was slightly safer, it also required a hash lookup every time we retrieved a parent.
This got expensive when there was a lot of tree walking, particularly given that we walk ancestors in some cases and we have to get the parent for NextSibling and PrevSibling.
Instead, mParent is now a RemoteAccessible pointer.
mChildren is already raw pointers (even when crossing documents) and we haven't encountered problems there recently, so I don't anticipate safety problems here.
Differential Revision: https://phabricator.services.mozilla.com/D218801
For example, one of the frames could be in the block's main in-flow line list and the other could be in an overflow list.
When this happens, it's not valid to compare LineIterators, so we must compare the line lists first.
Differential Revision: https://phabricator.services.mozilla.com/D218613
The [tab-close-button](https://searchfox.org/mozilla-central/rev/f9157a03835653cd3ece8d2dc713a782b7e4374e/browser/base/content/tabbrowser-tab.js#40) is not labeled and is missing an interactive role of button, while it is functioning as one.
Note: we do not want this control to be keyboard focusable, because keyboard-only user could close the tab via the context menu and we don't want to create an additional tab stop for the navigation as well, but making sure the control is marked up as a button with an accessible name would allow it to be actionable with speech-to-text software, with touch devices, with switch controls in scan mode, and for screen readers via their navigation shortcuts as well.
Differential Revision: https://phabricator.services.mozilla.com/D204413
This is now simply a matter of leveraging the work in the previous patches to support the new selection type and map it to the correct attribute.
There isn't an IAccessible2 or ATK attribute for this yet.
We use mark:true, based on <mark> and role="mark" which is used for a semantic highlight.
I've discussed this with Google, NV Access and Vispero and they all seem to be happy with this.
Differential Revision: https://phabricator.services.mozilla.com/D217071
nsISelectionListener isn't sufficient because it only notifies that the selection has changed.
A11y needs to know specifically which ranges were added or removed.
Previously, we handled this specifically for spelling errors in mozInlineSpellChecker.
That code has been removed and replaced with a more general approach.
Since we now have these notifications, rather than using nsISelectionListener just to fire events, we now use these notifications for that as well.
This avoids the need to add additional nsISelectionListeners, which would get messy particularly for custom highlights where there can be an arbitrary number of selections at any given time.
Differential Revision: https://phabricator.services.mozilla.com/D217068
Previously, this code was specifically tied to the spell check selection.
Actually adding more selection types will come in subsequent patches.
Differential Revision: https://phabricator.services.mozilla.com/D217066
An array of ints is fine for spelling errors, but we need to support multiple attributes like this.
We could use an array of ints for each attribute and search each one, though that would require more work in the parent process.
Also, custom highlights can have multiple selections for a single highlight type.
This would be rather messy with int arrays, especially where multiple selections span beyond the Accessible.
Differential Revision: https://phabricator.services.mozilla.com/D217065
This doesn't matter for spelling errors.
However, we will soon generalise this code for use with other attributes like this.
In particular, custom highlights require us to use AbstractRange.
While we aren't supporting custom highlights in this bug, it is more effective to do this as part of this major refactor rather than doing another refactor later.
Differential Revision: https://phabricator.services.mozilla.com/D217063
This test is disabled on CI because it's a bit fragile and we've never been able to work out how to fix that.
However, it's still useful locally.
Unfortunately, because it's disabled on CI, this problem wasn't caught when tests were moved around.
Differential Revision: https://phabricator.services.mozilla.com/D217062
Now, we have `nsFocusManager::GetFocusedElementStatic()` which returns focused
element if the `nsFocusManager` instance is available. Therefore, if
`nsFocusManager::GetFocusedElement()` users do not use other methods of
`nsFocusManager`, they can use `nsFocusManager::GetFocusedElementStatic()` and
make themselves simpler.
Note that some callers return early if `nsFocusManager` is not available, but
they do not return error and `nsFocusManager` instance is available in most
time of the life time of the process. Therefore, we can simply stop using the
early return.
Differential Revision: https://phabricator.services.mozilla.com/D217527
It's a rather useless interface:
* nsITextControlFrame is only implemented by nsTextControlFrame, so we
can just use that.
* nsIFormControlFrame had very few actual functionality, mostly
scattered around:
* SetFormProperty(select) was only useful for nsTextControlFrame.
* SetFormProperty(value) was only called on file controls.
* SetFocus() did mostly nothing, or things that can be done in
ElementStateChanged instead.
There are some do_QueryFrame calls that I replaced for better checks in
font inflation and nsIFrame, but I'll adjust to preserve behavior if you
insist (it just such a somewhat-random check).
Differential Revision: https://phabricator.services.mozilla.com/D217322
This matches the current shipping version of Chromium, and the last
version of the spec, except for the <slot> display when open, which per
spec ought to be `block`, but it's still `contents`.
animation-canceled-by-parent-details-element-being-closed.html is
invalid because content-visibility doesn't cancel animations, just
pauses them. It also times out in Chrome.
Differential Revision: https://phabricator.services.mozilla.com/D217192
This matches the current shipping version of Chromium, and the last
version of the spec, except for the <slot> display when open, which per
spec ought to be `block`, but it's still `contents`.
animation-canceled-by-parent-details-element-being-closed.html is
invalid because content-visibility doesn't cancel animations, just
pauses them. It also times out in Chrome.
Differential Revision: https://phabricator.services.mozilla.com/D217192
First, previously, we were doing this in registerCleanupFunction, but this actually runs after the entire test file has finished, not each task.
We need this to happen after each task because some tasks might set Python globals which might interfere with other tasks.
Second, even when this did run previously, we didn't actually wait until it was complete.
runPython() is async, so we need to wait for the Promise to be fulfilled.
Third, if we had awaited this previously, we would have hung forever.
The Python runner wasn't sending a response when it finished the reset, so the JS code never knew when it had completed.
We now just send a return of None in this case to signal completion.
Differential Revision: https://phabricator.services.mozilla.com/D215757
Previously, we assumed that CaretAssociationHint::Before always meant the caret was at the insertion point at the end of a line.
However, it can also mean that the caret is before the start of a node in the middle of a line.
To fix this, we need to check for line and paragraph boundaries.
See the code comments for details.
I moved this functionality completely out of HyperTextAccessible and into TextLeafPoint.
First, it was easiest to do these checks with private functions already available to TextLeafPoint.
Second, this ideally belongs in TextLeafPoint anyway; its existence in HyperTextAccessible was vestigial.
Differential Revision: https://phabricator.services.mozilla.com/D215089
Previously, we assumed that CaretAssociationHint::Before always meant the caret was at the insertion point at the end of a line.
However, it can also mean that the caret is before the start of a node in the middle of a line.
To fix this, we need to check for line and paragraph boundaries.
See the code comments for details.
I moved this functionality completely out of HyperTextAccessible and into TextLeafPoint.
First, it was easiest to do these checks with private functions already available to TextLeafPoint.
Second, this ideally belongs in TextLeafPoint anyway; its existence in HyperTextAccessible was vestigial.
Differential Revision: https://phabricator.services.mozilla.com/D215089
Previously, TextLeafPoint::GetCaret() returned a placeholder representation of the caret.
ActualizeCaret() was then used to get the real caret position, optionally adjusting for the line end depending on the caller's needs.
This causes problems when we need to store the TextLeafPoint information in a UIA text range object because the only way to indicate the line end insertion point is to use the GetCaret() placeholder, but that also means the stored position changes if the caret moves.
For example, if you disabled NVDA's "caret moves review cursor" setting and then moved the caret, the review cursor should stay at the old position, but it didn't previously.
To fix this:
1. TextLeafPoint now has a new mIsEndOfLineInsertionPoint flag which is set to true by GetCaret() if appropriate.
2. GetCaret() sets mAcc and mOffset immediately, rather than needing to call ActualizeCaret() later.
3. TextLeafPoint methods still need to adjust the point to correctly handle the line end insertion point in some cases, but that is now handled by the private TextLeafPoint::AdjustEndOfLine method.
4. FindBoundary now correctly returns the previous character/cluster when requested for this end of line insertion point. Strictly speaking, this bug always existed, but no existing callers ever triggered it.
Differential Revision: https://phabricator.services.mozilla.com/D214342
We already did this for BOUNDARY_CHAR, but i neglected to update this for cluster in bug 855184.
Without this, FindBoundary with BOUNDARY_CLUSTER on a caret TextLeafPoint when the caret is at the end of a line would return the last cluster instead of no character.
Differential Revision: https://phabricator.services.mozilla.com/D214341
Previously we checked if the announcement was a child of the root acc directly, but it's not clear this worked reliably since we've done `GetObjectOrRepresentedView` for a while, which (should) return the view instead of the root acc. This patch also:
- Dispatches the announcement from NSApp instead of NSWindow, since per chrome and safari notifs fired on non-main windows get dropped
- Modifies the announcement priority from medium to high, so VO interrupts itself to speak this message (this makes the UX more consistent, since the text-inserted/text-deleted notifs from the URL bar seem to occasionally bookend the announcement)
- Updates the browser_app.js test to NOT run in headless mode, since in headless mode NSApp isn't rendered to dispatch the notification. This test contains a task for AXAnnouncementRequested via a11yUtils.announce
Differential Revision: https://phabricator.services.mozilla.com/D206083
`eContextMenu` event may be fired from `widget`. Therefore, different from
`ePointerClick` and `ePointerAuxClick`, they may cross the process boundary,
may be handled by APZ and may be dispatched into the DOM after a delay.
Therefore, this patch is complicated than the previous patch. This adds
* New IPC message handlers for sending/receiving a `WidgetPointerEvent`
* New `DelayedPointerEvent` class and templated `MouseInput::ToWidgetEvent`
* `PresShell::EventHandler` handles `eContextMenu` as same as `WidgetMouseEvent`
Differential Revision: https://phabricator.services.mozilla.com/D213003
In bug 1779578, I changed the way a11y trees are serialised such that the parent id is included for each Accessible.
When de-serialising in DocAccessibleParent::RecvShowEvent, in order to avoid a theoretical performance regression caused by repeatedly looking up the same parent, I added an optimisation to use the last parent if it is the same as the current parent.
Unfortunately, it seems I never actually set the lastParent and lastParentID variables, so this optimisation was a no-op!
This is a micro-optimisation: it doesn't seem to make any observable difference.
However, it seems silly to have effectively dead code and it's a very straightforward fix.
Differential Revision: https://phabricator.services.mozilla.com/D213177
1. HyperTextAccessibles already cache language and RemoteAccessible::Language uses this.
2. Previously, we didn't cache language for a non-text, non-HyperText Accessible at all. This includes images and HTML radio buttons. Now we cache it as a top level attribute in this case and return it in RemoteAccessible::Language.
3. We previously cached language for a text (leaf) Accessible where the language differed from its parent, but we never used this in RemoteAccessible::Language, only when calculating text attributes. Now we use it in RemoteAccessible::Language as well.
4. Where a text (leaf) Accessible's language is the same as its parent, RemoteAccessible::Language now gets this from the parent.
Differential Revision: https://phabricator.services.mozilla.com/D212503
Previously we checked if the announcement was a child of the root acc directly, but it's not clear this worked reliably since we've done `GetObjectOrRepresentedView` for a while, which (should) return the view instead of the root acc. This patch also:
- Dispatches the announcement from NSApp instead of NSWindow, since per chrome and safari notifs fired on non-main windows get dropped
- Modifies the announcement priority from medium to high, so VO interrupts itself to speak this message (this makes the UX more consistent, since the text-inserted/text-deleted notifs from the URL bar seem to occasionally bookend the announcement)
- Updates the browser_app.js test to NOT run in headless mode, since in headless mode NSApp isn't rendered to dispatch the notification. This test contains a task for AXAnnouncementRequested via a11yUtils.announce
Differential Revision: https://phabricator.services.mozilla.com/D206083
Most OS APIs want a cluster when they ask for a "character", except ATK.
Rather than altering BOUNDARY_CHAR, I added a new BOUNDARY_CLUSTER.
Aside from being less risky and causing less churn, there are cases internally where we want to move a TextLeafPoint by character; e.g. to explicitly move to the next/previous Accessible or to move to the next/previous character in an abstract way without worrying about Accessible boundaries.
Calculating clusters is more expensive, so it doesn't make sense to move by cluster in those cases.
Differential Revision: https://phabricator.services.mozilla.com/D212517
In order to keep all of the tragic implementation detail for this function in a single class, I originally put the structs and the thread proc inside the function.
The thread proc was implemented as a lambda which implicitly converts to a function pointer.
Unfortunately, it seems MinGW can't implicitly convert this lambda to a function with the stdcall calling convention.
This is why we can't have nice things.
To deal with this, refactor it into a class so that we can define the thread proc as a static function instead of a lambda.
All of the methods are static; the class is just used to contain the implementation details.
Differential Revision: https://phabricator.services.mozilla.com/D212391
Querying some pipe handles can cause a hang and there is no way to prevent this other than terminating the thread.
See the discussion on the bug for more details and research.
Therefore, query the pipes in another thread.
If the thread takes too long, terminate it and resume querying other handles in another thread.
Differential Revision: https://phabricator.services.mozilla.com/D212088
Previously we checked if the announcement was a child of the root acc directly, but it's not clear this worked reliably since we've done `GetObjectOrRepresentedView` for a while, which (should) return the view instead of the root acc. This patch also:
- Dispatches the announcement from NSApp instead of NSWindow, since per chrome and safari notifs fired on non-main windows get dropped
- Modifies the announcement priority from medium to high, so VO interrupts itself to speak this message (this makes the UX more consistent, since the text-inserted/text-deleted notifs from the URL bar seem to occasionally bookend the announcement)
- Updates the browser_app.js test to NOT run in headless mode, since in headless mode NSApp isn't rendered to dispatch the notification. This test contains a task for AXAnnouncementRequested via a11yUtils.announce
Differential Revision: https://phabricator.services.mozilla.com/D206083
`PresShell::GetRootScrollFrameAsScrollable()` is equivalent to
`PresShell::GetRootScrollContainerFrame()`.
In ScrollContainerFrame.h, `DecideScrollableLayer()` has two versions, one has
four parameters, and the other has five parameters with the fifth parameter
`aDirtyRectHasBeenOverriden` having a default value `nullptr`. When we switch
the caller from `nsIScrollableFrame` to `ScrollContainerFrame`, we need to
remove the default value for the fifth parameter to avoid ambiguity.
Differential Revision: https://phabricator.services.mozilla.com/D211494
Also, simplify some callers of `GetScrollTargetFrame()` to drop
`nsIScrollableFrame*` and unnecessary `do_QueryFrame`. We'll continue removing
more `nsIScrollableFrame*` in later parts.
Differential Revision: https://phabricator.services.mozilla.com/D211490
Previously, we listened for changes to the disabled attribute itself.
However, this doesn't handle the case that the disabled state is inherited from a fieldset ancestor.
In contrast, DOM notifies us about changes to ElementState::DISABLED on form control descendants when a fieldset gains or loses the disabled attribute.
Differential Revision: https://phabricator.services.mozilla.com/D211688
`PresShell::GetRootScrollFrameAsScrollable()` is equivalent to
`PresShell::GetRootScrollContainerFrame()`.
In ScrollContainerFrame.h, `DecideScrollableLayer()` has two versions, one has
four parameters, and the other has five parameters with the fifth parameter
`aDirtyRectHasBeenOverriden` having a default value `nullptr`. When we switch
the caller from `nsIScrollableFrame` to `ScrollContainerFrame`, we need to
remove the default value for the fifth parameter to avoid ambiguity.
Differential Revision: https://phabricator.services.mozilla.com/D211494
Also, simplify some callers of `GetScrollTargetFrame()` to drop
`nsIScrollableFrame*` and unnecessary `do_QueryFrame`. We'll continue removing
more `nsIScrollableFrame*` in later parts.
Differential Revision: https://phabricator.services.mozilla.com/D211490
Continuations occur when text wraps onto a new line (fluid continuations), but they also occur when the text direction changes (non-fluid continuations).
Previously, TextLeafRange assumed that all continuations were line breaks.
Now, we explicitly treat fluid continuations as line breaks.
It's also possible for a non-fluid continuation to be on a different line if the text direction changes between the end of the previous line and the start of another.
In that case, we must use a line iterator to check whether they are on different lines.
Differential Revision: https://phabricator.services.mozilla.com/D210893
As per the comments it isn't supported with cache-the-world on, it's
barely documented if at all, and a test for it seems to be failing
without me being able to reproduce it at least (tried on both windows
and Linux).
I don't think it's worth digging too much more into it. My guess is a
reentrant / differently timed a11y event caused by my scheduling
changes, or so, which would override sEventTargetNode or the other
static bool.
The test has ~always failed on macOS too...
Differential Revision: https://phabricator.services.mozilla.com/D210872
When we create a TextLeafAccessible for a CSS pseudo-element, we already use the alt text if present.
However, it seems layout sometimes re-renders the text of pseudo-elements.
Previously, a11y would update the text in this case like it would for any other TextLeafAccessible, thus overwriting the alt text with the text rendered by layout.
To fix this, we now skip updating text if CSS alt text is present.
Differential Revision: https://phabricator.services.mozilla.com/D211139
Previously, we only included the subtree for roles which are allowed to be traversed during recursive name computation.
This meant that no text would be produced for live regions with roles such as status, where name computation traversal is not allowed.
Now, we first get the name to handle cases where the name is explicitly specified; e.g. images with alt text.
We then add the subtree text if the name wasn't already computed from it.
Differential Revision: https://phabricator.services.mozilla.com/D210628
This revision updates outdated comments in nsTextEquivUtils that refer to
previous names for steps of the Accessible Name and Description Computation
specification. It updates the comments to the new, named computation steps.
Additionally, this revision cleans up and adds other comments to make reading
the code a bit easier.
Differential Revision: https://phabricator.services.mozilla.com/D211110
The Acc Name spec requires that UAs should only follow aria-labelledby and
aria-describedby IDREFs "if [...] the current node is not already part of an
ongoing aria-labelledby or aria-describedby traversal." It also requires
that "[e]ach node in the subtree is consulted only once." This revision
implements these rules and updates relevant tests, including removal of WPT
expected-fail designations. The concept of sInitiatorAcc has been expanded - we
now track all referenced accessibles. We also track whether we're in an
aria-labelledby or aria-describedby traversal.
Differential Revision: https://phabricator.services.mozilla.com/D209617
As well as plain strings, alt text items can get their text from an attribute on the Element.
We need to include the values of those attributes when we compute alt text.
In addition, we must watch for changes to these attributes and update the accessibility tree or fire events as necessary.
Differential Revision: https://phabricator.services.mozilla.com/D210018
CSS alt text makes most sense for an image.
However, even when the content property specifies text, you can still specify alt text!
To support this, this patch does two things:
1. Uses the alt text for the TextLeafAccessible instead of the primary text.
2. Tweaks nsTextEquivUtils to use the alt text when gathering text from a subtree.
As with the last patch, changing the CSS content replaces the pseudo-element, which in turn replaces the Accessible with a new one, so we don't need any additional code to handle updates.
Differential Revision: https://phabricator.services.mozilla.com/D210017
Previously, a11y did get notified about CSS images, but we chose not to create Accessibles for them.
This patch allows us to create an ImageAccessible for a CSS image if it has alt text.
Since there is now an Accessible, the previous patch will then mean that Accessible::Name will return the CSS alt text.
Changing the CSS content replaces the pseudo-element, which in turn replaces the Accessible with a new one, so we don't need any additional code to handle updates.
Differential Revision: https://phabricator.services.mozilla.com/D210016
This directly handles the case where the CSS content property replaces the content of an element with an image plus alt text.
It is also needed to correctly return the alt text for a pseudo-element ImageAccessible, as implemented in a subsequent patch.
Differential Revision: https://phabricator.services.mozilla.com/D210015
This allows us to check for alt text and also to output all of it to a string.
For now, this only supports plain strings, but this will be extended in a subsequent patch.
Differential Revision: https://phabricator.services.mozilla.com/D210014
Without this, a new source file introduced in a subsequent patch causes the compiler to become confused about which TreeWalker we mean: a11y::TreeWalker or dom::TreeWalker.
I don't really understand why this starts happening, but I'm guessing it is related to our unified builds.
Differential Revision: https://phabricator.services.mozilla.com/D210013
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
Not sure how testable this is, for a11y purposes. The other consumer is
some XRSession stuff which doesn't seem to care too much about the
timing of this.
Differential Revision: https://phabricator.services.mozilla.com/D210384
There's no call to AddRefreshObserver(FlushType::Layout), so we don't
need to track layout flushes. The only reason we need
mLayoutFlushObservers is so that reflows triggered from the style flush
get processed. But at that point, we can just flush layout directly.
There's no really good distinction between style flushes and layout
flushes with container queries anyways, so this makes the code simpler
to reason about.
Differential Revision: https://phabricator.services.mozilla.com/D209924
We already did this for ARIA role="progress" per the Core AAM spec.
Per the HTML AAM spec, HTML <progress> should map to ARIA role progress.
Differential Revision: https://phabricator.services.mozilla.com/D209903
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
1. The ARIA role should take precedence over the HTML tag.
2. The ARIA region role should only be conditionally treated as a landmark. Use the Gecko role to determine this.
3. Change some other cases to use the Gecko role instead of directly checking the name for consistency and to avoid duplicated logic.
These fixes are tested in the next patch.
Differential Revision: https://phabricator.services.mozilla.com/D209099
1. The ARIA role should take precedence over the HTML tag.
2. The ARIA region role should only be conditionally treated as a landmark. Use the Gecko role to determine this.
3. Change some other cases to use the Gecko role instead of directly checking the name for consistency and to avoid duplicated logic.
These fixes are tested in the next patch.
Differential Revision: https://phabricator.services.mozilla.com/D209099
This allows tests to get an Accessible for an HTML area element, since area elements are special and are not in the DocAccessible node map.
Differential Revision: https://phabricator.services.mozilla.com/D209614
This doesn't change behavior on its own, but it's likely we want to make
the tab focusability more complicated in bug 1895184, and this will make
changes to this area less painful.
Differential Revision: https://phabricator.services.mozilla.com/D209525
Add more FAQs for engineers working with the a11y_checks results and include a link to the Mochitest FAQ to debug a11y-checks in the Accessibility docs section.
Differential Revision: https://phabricator.services.mozilla.com/D208393
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
Previously, we did this for any focused, selectable item.
However, the ARIA spec says we should only do this for option, tab and treeitem.
In particular, we shouldn't do this for gridcell, as this can expose gridcells as selected when they aren't.
Differential Revision: https://phabricator.services.mozilla.com/D209132
We return the implicit role in ARIATransformRole, but that doesn't change the role map entry.
However, ApplyARIAState uses the role map entry to figure out what states are relevant.
To fix this, ApplyARIAState now checks for this case and gets the correct role map entry before applying states.
Differential Revision: https://phabricator.services.mozilla.com/D208855
This revision reverts the changes that trimmed non-breaking spaces from the
start and end of accessible names. The web platform group has decided that
those tests weren't valid as-is; the correct behavior is not to trim those
characters. This revision also removes expected-fail designations from
affected tests.
Differential Revision: https://phabricator.services.mozilla.com/D208687
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
Since SVG elements aren't in a markup map, Gecko doesn't check for them when
searching markup maps while determining whether to create an accessible in
display:contents contexts. This revision addresses the problem by factoring out
the SVG creation code and using it in two places - newly in the dislay:contents
code. This revision also removes expected failures from relevant web platform
tests.
Differential Revision: https://phabricator.services.mozilla.com/D207943
This makes accessing `Manager()` on an IPDL protocol safer, and replaces the
previous ActorLifecycleProxy reference, which would only keep the manager alive
until IPDL drops its reference.
Unfortunately this introduces some leaks due to reference cycles, which will be
fixed in follow-up parts.
Differential Revision: https://phabricator.services.mozilla.com/D198624
Previously we checked if the announcement was a child of the root acc directly, but it's not clear this worked reliably since we've done `GetObjectOrRepresentedView` for a while, which (should) return the view instead of the root acc. This patch also:
- Dispatches the announcement from NSApp instead of NSWindow, since per chrome and safari notifs fired on non-main windows get dropped
- Modifies the announcement priority from medium to high, so VO interrupts itself to speak this message (this makes the UX more consistent, since the text-inserted/text-deleted notifs from the URL bar seem to occasionally bookend the announcement)
- Updates the browser_app.js test to NOT run in headless mode, since in headless mode NSApp isn't rendered to dispatch the notification. This test contains a task for AXAnnouncementRequested via a11yUtils.announce
Differential Revision: https://phabricator.services.mozilla.com/D206083
