Keeping accessibilityAttributeNames because it calls additionalAccessibilityAttributeNames
which is used by subclasses.
Differential Revision: https://phabricator.services.mozilla.com/D77335
Add most attributes getters, setters and actions to prottocol,
autogenerate objective c dictionaries, and implement forwarding
logic from NSAccessibility methods.
Differential Revision: https://phabricator.services.mozilla.com/D76921
This sets up the possibility of moving most non-gecko things to a base class, and
start a protocol to add for all the subclasses to implement as needed.
Differential Revision: https://phabricator.services.mozilla.com/D76920
There's no use case for stateful comparators, so they can be just plain
function pointers.
This is used in some hot places like CSS selector matching.
Differential Revision: https://phabricator.services.mozilla.com/D77084
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
Previously, to get the column headers for a cell when there weren't explicit headers, we walked over all previous cells in the column looking for headers.
For large tables with thousands of rows, this was very expensive, particularly when Windows screen readers rendered virtual buffers, fetching headers for all cells.
To speed this up, we now lazily cache the previous column header for each cell.
We even cache whether there is no previous header, since that is quite common and we don't want to pointlessly walk in that case.
Subsequent cells utilise the cached values (if any) for prior cells.
We don't store the cache on individual TableCellAccessibles because that would require us to walk all cells to invalidate the cache, even if few or no cells had cached values.
Instead, we store the cache as a hash table on the TableAccessible.
This way, we can just clear the cache whenever a column header is added to the tree.
We invalidate the cache whenever a column header is bound to its parent.
We don't need to invalidate the cache for removals because we instead just ignore defunct Accessibles in the cache.
Differential Revision: https://phabricator.services.mozilla.com/D76106
In favor of the NativeAnonymous versions which they forward to.
Done automatically with:
rg -l 'IsInAnonymousSubtree' | xargs sed -i 's/IsInAnonymousSubtree/IsInNativeAnonymousSubtree/g'
And removing the function definitions afterwards.
Differential Revision: https://phabricator.services.mozilla.com/D76681
These tests insert a <browser> into the DOM via tabbrowser, and
immediately try to get a hold to the underlying document right after.
However the a11y tree is constructed after frame construction, and with
bug 1584935 there's no longer a guarantee that it gets done in time
without these explicit flushes.
Note that I couldn't reproduce these failures locally, so take the
diagnostic with a grain of salt, but I believe it's accurate and that
this is the right fix.
Differential Revision: https://phabricator.services.mozilla.com/D75715
For an OOP iframe, the logged parent will be null and the logged root won't be the real top level document.
This is just the way things are and this might still be useful info sometimes, so we still log it, but make it clear in the log message that it's about the in-process tree.
Differential Revision: https://phabricator.services.mozilla.com/D74587
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
To improve performance for cross-process COM, we disable COM garbage collection in content processes for calls from our parent process.
However, this means we don't receive Release calls from in-process a11y clients.
For an Accessible, we get around this by explicitly disconnecting remote clients when the Accessible shuts down.
This doesn't cover COM objects which aren't interfaces of an Accessible; i.e. where the object has a different IUnknown to the Accessible.
This patch adds AccessibleWrap::AssociateCOMObjectForDisconnection to allow these objects to be tracked.
Tracked objects are then disconnected when the Accessible shuts down.
Differential Revision: https://phabricator.services.mozilla.com/D74999
Platform accessibles from proxies were not getting pruned. Also, there is no need
to walk up ancestors to find a pruning container since all pruning containers have direct
leaf children.
Differential Revision: https://phabricator.services.mozilla.com/D72482
This is something that was implemented a long time ago, but it isn't covered in any spec, other browsers don't implement it and I don't know of any usage in the wild.
This doesn't work with OOP iframes, since what we're doing here requires the documents to be in the same process.
Given it isn't used or specified, the simplest solution is to just remove the behaviour altogether.
Differential Revision: https://phabricator.services.mozilla.com/D74628
This depends on richlistitem's nsIDOMXULSelectControlItemElement::label implementation, which does the wrong thing in several cases.
We could make this use a11y name computation, but I can't find any other list box implementation that exposes accessible value on the list box itself, so I don't see any reason to keep this.
Differential Revision: https://phabricator.services.mozilla.com/D74372
This is not strictly related to this bug, but I'm touching the surrounding code and I've been confused by this on several occasions.
The previous comments suggested that NameFromAssociatedXULLabel (which uses XULLabelIterator) looks at child labels.
This is incorrect: XULLabelIterator only looks at <label control="id">.
The inclusion of child labels in the name comes from GetNameFromSubtree, which is called elsewhere.
Differential Revision: https://phabricator.services.mozilla.com/D74371
This was only used for richlistitems, but the richlistitem implementation of this property did the wrong thing in several cases.
The a11y engine's label computation code generally does a better job.
Where the label does need to be overridden in specific cases, we should use ARIA instead.
Differential Revision: https://phabricator.services.mozilla.com/D74370
As of bug 1621451 this argument was ignored, but it just silently runs your code with `python3` if you pass it anyway. Ensure this doesn't happen any more, and protect against any other unexpected arguments as well.
Differential Revision: https://phabricator.services.mozilla.com/D73485
`ply`, [by design](https://github.com/dabeaz/ply/issues/79), does not produce reproducible table files; hence bug 1633156. (Note that this was *always* true, but only became a problem once we switched to Python 3, which has more unpredictable dict iteration order than Python 2.7, at least prior to [3.7](https://docs.python.org/3/whatsnew/3.7.html#summary-release-highlights).)
In any other circumstance I would consider submitting a patch to `ply` to fix this, but as of the [in-progress version 4.0 of the library](https://github.com/dabeaz/ply/blob/master/CHANGES), it doesn't even emit this cached data any more, and indeed the [latest version of the code](1fac9fed64/ply) doesn't even call `open()` at all except to do logging or to read the text data to be parsed from `stdin`. So if we were going to pin our future on `ply` and upgrade to later versions of the library in the future, we would have to live in a world where `ply` doesn't generate cached table files for us anyway.
Emitting the cached table files so later build steps can consume them is an "optimization", but it's not clear exactly how much actual value that optimization provides overall. Quoth the `CHANGES` file from that repository:
```
PLY no longer writes cached table files. Honestly, the use of
the cached files made more sense when I was developing PLY on
my 200Mhz PC in 2001. It's not as much as an issue now. For small
to medium sized grammars, PLY should be almost instantaneous.
```
In practice, I have found this to be true; namely, `./mach build pre-export export` takes just about as long on my machine after this patch as it did before, and in a try push I performed, there's no noticeable performance regression from applying this patch. In local testing I also found that generating the LALR tables in calls to `yacc()` takes about 0.01s on my machine generally, and we generate these tables a couple dozen times total over the course of the `export` tier now. This isn't *nothing*, but in my opinion it's also not nearly long enough where it would be a concern given how long `export` already takes.
That `CHANGES` file also stresses that if caching this data is important, we have the option of doing so via `pickle`. If and when we decide that re-enabling this optimization is valuable for us, we should take control of this process and perform the generation in such a way that we can guarantee reproducibility.
Differential Revision: https://phabricator.services.mozilla.com/D73484
In-process iframes get a DocAccessibleChild, even though they're not top level in their process.
However, the parent IAccessible on DocAccessibleChild (sent from the parent process) is only relevant for the top level.
Previously, we used the parent IAccessible on the DocAccessibleChild for *all* documents, resulting in accParent returning null for in-process iframe documents.
Instead, we need to use the base implementation in this case.
Differential Revision: https://phabricator.services.mozilla.com/D74180
This removes the need for FrameForPointOptions::IsRelativeToLayoutViewport,
and makes sure each call site of these functions indicates whether the
input point/rect is in visual or layout coordinates.
Several call sites were passing in layout coordinates without setting the
IsRelativeToLayoutViewport flag, which this patch corrects.
Differential Revision: https://phabricator.services.mozilla.com/D71705
The code in mozAccessible SubRole was actually never executed for inputs, so the SearchField sub role was never set. Moved the implementation to mozTextAccessible. Also reenabled the tests from bug 1634373, which now pass.
Depends on D73308
Differential Revision: https://phabricator.services.mozilla.com/D73735
When an Accessible is removed, the AccGroupInfo for its siblings is marked dirty.
However, when AccGroupInfo::Update is called, it previously didn't clear mParent, which is used for the NODE_CHILD_OF relation.
This meant that if the conceptual group parent was removed and there was subsequently no conceptual parent, NODE_CHILD_OF would return an incorrect (potentially dead) Accessible.
Differential Revision: https://phabricator.services.mozilla.com/D73776
Fixes tooltips/menus in responsive design mode. A few accesibility tests
had to be adjusted since tooltips are now automatically created
for them.
Differential Revision: https://phabricator.services.mozilla.com/D72400
I also simplified mozTextLeafAccessible by redirecting value to title. And removing some dead methods. It previously was calling Text() on the text accessible, but this is not necessary since Name() returns
the same value.
Differential Revision: https://phabricator.services.mozilla.com/D72584
This removes the need for FrameForPointOptions::IsRelativeToLayoutViewport,
and makes sure each call site of these functions indicates whether the
input point/rect is in visual or layout coordinates.
Several call sites were passing in layout coordinates without setting the
IsRelativeToLayoutViewport flag, which this patch corrects.
Differential Revision: https://phabricator.services.mozilla.com/D71705
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
This is the recommended role in the HTML Accessibility API Mappings draft[1].
Although Chrome and Safari just expose unlinked a tags as AXStaticText.
They also don't update the accessble if it gets an href. So while we
are doing this a bit differently, I think it is probably better. And VO is happy.
1. https://www.w3.org/TR/html-aam-1.0/#html-element-role-mappings
Differential Revision: https://phabricator.services.mozilla.com/D71260
I want to generalize it for other link stuff. Need a separate commit or
it is not recognized as a move, and won't retain history. For some reason.
Differential Revision: https://phabricator.services.mozilla.com/D71259
addA11yLoadEvent gets the contentWindow and wait for the document from that window to fire the load event.
Enabling the DocumentChannel for parent process load (or here in non-e10s mode) we have one extra event loop before the load starts.
So the window passed to addAllyLoadEvent would have been of the about:blank page.
The current code was based on an observable behaviour which was that the load was occuring synchronously.
DocumentChannel broke that assumption.
Differential Revision: https://phabricator.services.mozilla.com/D70799
We need it to live in BrowsingContext instead of WindowContext, because
we need to preserve the zoom level across same-origin navigation.
It'd be nice if it only lived in the top BC, but that's not possible at
the moment because a lot of tests rely on zooming only iframes. Some of
them can be adjusted for scaling the top instead, but not sure it's
worth it's worth fixing them and moving the zoom to be top-only, as it'd
be a bunch of effort, and the complexity and overhead of propagating the
zoom is not so big.
The print-preview-specific code in nsContentViewer is from before we did
the document cloning setup, and it seems useless. I've tested print
preview scaling before and after my patch and both behave the same.
The rest is just various test changes to use the SpecialPowers APIs or
BrowsingContext as needed instead of directly poking at the content
viewer.
I named the pres context hook RecomputeBrowsingContextDependentData, as
more stuff should move there like overrideDPPX and other media emulation
shenanigans.
I also have some ideas to simplify or even remove ZoomChild and such,
but that's followup work.
Differential Revision: https://phabricator.services.mozilla.com/D71969
When the tree is mutated, we set eGroupInfoDirty regardless of whether there is GroupInfo.
Previously, we cleared eGroupInfoDirty when updating GroupInfo, but not when creating it.
This meant that the flag was often still set, causing the cache to not be used a lot of the time.
Differential Revision: https://phabricator.services.mozilla.com/D72139
addA11yLoadEvent gets the contentWindow and wait for the document from that window to fire the load event.
Enabling the DocumentChannel for parent process load (or here in non-e10s mode) we have one extra event loop before the load starts.
So the window passed to addAllyLoadEvent would have been of the about:blank page.
The current code was based on an observable behaviour which was that the load was occuring synchronously.
DocumentChannel broke that assumption.
Differential Revision: https://phabricator.services.mozilla.com/D70799
In order for a form control to be labelled by an ancestor HTML label, its Accessible must return true for isWidget().
Also, HTML AAM says the text-input-type attribute should be exposed.
Differential Revision: https://phabricator.services.mozilla.com/D72080
We already skipped descendants for eNameFromSubtreeIfReqRule when the element wasn't labelled by something else; i.e. when calling GetNameFromSubtree.
However, when such an element is labelled/described by an ancestor, we compute the text equiv for the label using AppendTextEquivFromContent.
Previously, when descending from the ancestor down into the element itself, we would descend into its subtree despite eNameFromSubtreeIfReqRule.
This meant that groupings labelled/described by ancestor would include the content of the grouping itself in its label/description.
This was causing problems for time inputs (once those can accept an ancestor label in the next patch).
Differential Revision: https://phabricator.services.mozilla.com/D72079
addA11yLoadEvent gets the contentWindow and wait for the document from that window to fire the load event.
Enabling the DocumentChannel for parent process load (or here in non-e10s mode) we have one extra event loop before the load starts.
So the window passed to addAllyLoadEvent would have been of the about:blank page.
The current code was based on an observable behaviour which was that the load was occuring synchronously.
DocumentChannel broke that assumption.
Differential Revision: https://phabricator.services.mozilla.com/D70799
I want to generalize it for other link stuff. Need a separate commit or
it is not recognized as a move, and won't retain history. For some reason.
Differential Revision: https://phabricator.services.mozilla.com/D71259
When an element with overflow:auto becomes scrollable, either by a style change or growing children, it should become focusable and fire a state change. Same in the inverse.
Differential Revision: https://phabricator.services.mozilla.com/D70561
--HG--
extra : moz-landing-system : lando
Changes to attributes such as disabled, contenteditable, and tabindex should cause FOCUSABLE
state changes to be fired when indeed the accessible gains or loses focusability.
Differential Revision: https://phabricator.services.mozilla.com/D70560
--HG--
extra : moz-landing-system : lando
addA11yLoadEvent gets the contentWindow and wait for the document from that window to fire the load event.
Enabling the DocumentChannel for parent process load (or here in non-e10s mode) we have one extra event loop before the load starts.
So the window passed to addA11yLoadEvent would have been of the about:blank page.
The current code was based on an observable behaviour which was that the load was occuring synchronously.
DocumentChannel broke that assumption.
Differential Revision: https://phabricator.services.mozilla.com/D70799
--HG--
extra : moz-landing-system : lando
This code has pretty much always been broken, we've started to flush
more because we fixed a bug that was not looking at XUL trees inside
shadow DOM in bug 1625991.
We cannot flush layout from a11y tree construction.
Differential Revision: https://phabricator.services.mozilla.com/D70917
--HG--
extra : moz-landing-system : lando
I really don't understand why this is what VoiceOver needs, but it seems to do the trick.
Differential Revision: https://phabricator.services.mozilla.com/D70776
--HG--
extra : moz-landing-system : lando
We need to do this because we can't rely on the main children cache invalidation.
Also, I don't think this really worked before with cell additions to a row, since only
the row's children would be invalidated, and the table's children would remain untouched.
Differential Revision: https://phabricator.services.mozilla.com/D69879
--HG--
extra : moz-landing-system : lando
The latter seems more accurate to what that method does, since we don't necessarily
forward that event to the OS, but might instead use it to update cached properties.
Differential Revision: https://phabricator.services.mozilla.com/D69878
--HG--
extra : moz-landing-system : lando
For OOP iframe documents, we can't support NODE_CHILD_OF in the usual way, since the iframe resides in a different process.
Previously, we incorrectly returned the application accessible.
This was breaking focus ancestry walking for JAWS.
Instead, don't expose NODE_CHILD_OF at all in this case.
This is fine because the client will then request the parent instead, which will be correctly handled by platform/AccessibleOrProxy code.
Differential Revision: https://phabricator.services.mozilla.com/D70163
--HG--
extra : moz-landing-system : lando
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
D67954 starts using shadow DOM for menulist and slots the menulist children. This causes GetFlattenedTreeParent to return the slot instead of the parent menulist. This patch fixes it.
Differential Revision: https://phabricator.services.mozilla.com/D70234
--HG--
extra : moz-landing-system : lando
Not sure how this could happen, but perhaps the tab is already focused so waiting
for a focus change event causes a timeout.
Differential Revision: https://phabricator.services.mozilla.com/D70059
--HG--
extra : moz-landing-system : lando
Having this kind of method will let us know what the states of interest are.
If all the states are cached we can return them without inquiring the full state.
Differential Revision: https://phabricator.services.mozilla.com/D69130
--HG--
extra : moz-landing-system : lando
In this patch set I'll introduce state caching, so I thought it's a good idea
to first add a bunch of tests to features that will be touched.
Differential Revision: https://phabricator.services.mozilla.com/D69129
--HG--
extra : moz-landing-system : lando
When checking if a parent of a table row counts for a table, take into account that a table might be an ARIAGridAccessible, which remains a generic hyperText, but is still a valid table. Tables with display: block; are such candidates.
Differential Revision: https://phabricator.services.mozilla.com/D68955
--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
This changes the ATK code to use AccessibleOrProxy::ChildAtPoint, since that already handles walking into OuterDocAccessibles appropriately.
Previously, atk_component_ref_accessible_at_point didn't work at all on OuterDocAccessibles.
Also, for ProxyAccessibles, we no longer adjust the coordinates for ATK_XY_WINDOW in the content process, as this depends on stuff that doesn't exist cross-platform and thus can't be used with AccessibleOrProxy.
Instead, we now handle this in the parent process before making the IPC call.
Differential Revision: https://phabricator.services.mozilla.com/D67986
--HG--
extra : moz-landing-system : lando
This makes it possible to get the `representedView` even after the accessible goes away on shutdown.
Differential Revision: https://phabricator.services.mozilla.com/D68489
--HG--
extra : moz-landing-system : lando
Dev Tools A11y Panel interacts with accessibles in the process in which they reside.
It does not (and cannot) deal with ProxyAccessibles.
However, GetDeepestChildAtPoint now walks into the ProxyAccessible tree if appropriate, which is what we want for tests and what normally makes sense.
This patch introduces GetDeepestChildAtPointInProcess, which Dev Tools will use instead.
Differential Revision: https://phabricator.services.mozilla.com/D68302
--HG--
extra : moz-landing-system : lando
This was an oversight in the HTMLGroupBoxAccessible implementation of NativeName, others trim their whitespaces by default.
Differential Revision: https://phabricator.services.mozilla.com/D68198
--HG--
extra : moz-landing-system : lando
This rejiggers a bit the way selection focus is handled so that focusing a
disabled form control with the mouse handles selection properly, and hides the
document selection and so on.
This matches the behavior of other browsers as far as I can tell.
Given now readonly and disabled editors behave the same, we can simplify a bit
the surrounding editor code.
Differential Revision: https://phabricator.services.mozilla.com/D66464
--HG--
extra : moz-landing-system : lando
Previously, we fired these for Accessibles, but this was never implemented for ProxyAccessibles (remote content documents).
Differential Revision: https://phabricator.services.mozilla.com/D67271
--HG--
extra : moz-landing-system : lando
This rejiggers a bit the way selection focus is handled so that focusing a
disabled form control with the mouse handles selection properly, and hides the
document selection and so on.
This matches the behavior of other browsers as far as I can tell.
Given now readonly and disabled editors behave the same, we can simplify a bit
the surrounding editor code.
Differential Revision: https://phabricator.services.mozilla.com/D66464
--HG--
extra : moz-landing-system : lando
nsFocusManager::GetFocusedWindow may return a window even if focus is actually inside an embedded OOP iframe.
Instead, use nsFocusManager::GetFocusedBrowsingContext, which always knows about the current focus across all processes.
If the focused context is in this process, we get its document and return it.
Differential Revision: https://phabricator.services.mozilla.com/D64514
--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
Previously, these stopped at an OuterDocAccessible.
Now, if an OuterDocAccessible is encountered, they continue the search in the remote child document.
As part of this, the bulk of the code has been moved into AccessibleOrProxy, since other callers might find this useful in future.
Also, xpcAccessible::ChildAtPoint now works on Windows.
Differential Revision: https://phabricator.services.mozilla.com/D66534
--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
I made more generalized mozSelectableAccessible and
mozSelectableChildAccessible classes for other things that will need
this kind of support.
Differential Revision: https://phabricator.services.mozilla.com/D66304
--HG--
extra : moz-landing-system : lando
As the message above suggests this does two things:
1. We filter out the invisible popup menus from the root's children.
2. We dispatch menu opened and closed events.
The latter helps VoiceOver retain some context about the mutating tree and notify the user about the menu.
Differential Revision: https://phabricator.services.mozilla.com/D65612
--HG--
extra : moz-landing-system : lando
This is to match the actual class it implements.
Differential Revision: https://phabricator.services.mozilla.com/D65611
--HG--
rename : accessible/mac/mozDocAccessible.h => accessible/mac/mozRootAccessible.h
rename : accessible/mac/mozDocAccessible.mm => accessible/mac/mozRootAccessible.mm
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
Previously, the following scenario was possible:
1. aria-activedescendant is used on a menupopup to set a11y focus. When the event is processed, FocusManager::mLastFocus gets set accordingly.
2. aria-activedescendant on the menupopup is changed, so a focus event gets queued.
3. Before that focus event can be processed, the Accessible in (1) gets unbound from the a11y tree.
4. DocAccessible::UnbindFromDocument checks whether the Accessible is the last focus. As per (1), it is.
5. It then tells FocusManager to reset the active item, causing it to throw away the active item set in (2) and fire focus on the DOM focus (which is not the menupopup).
This breaks the new select dropdown implementation.
To fix this, we now set mLastFocus in DispatchFocusEvent (when the event is queued) instead of ProcessFocusEvent.
This way, we don't override a pending new focus change unintentionally.
Differential Revision: https://phabricator.services.mozilla.com/D65706
--HG--
extra : moz-landing-system : lando
When looking to see if a row has a table, now also include generic text container accessibles in addition to row groups.
Also, when iterating through rows from a table, take into account that rows may be wrapped in generic text container accessibles.
Differential Revision: https://phabricator.services.mozilla.com/D65158
--HG--
extra : moz-landing-system : lando
Android does not currently have anything similar to a 'required' state
to indicate that a field or input is required before submission. In this
patch we append a localized "required" string onto the node's hint.
The hint typically has the description of the node. If the node is an
entry the hint will have its label followed by the description.
Differential Revision: https://phabricator.services.mozilla.com/D65215
--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
This is similar to the fix in bug 1614079 where we need to account
for a descendant that might match past a process boundary.
Differential Revision: https://phabricator.services.mozilla.com/D63974
--HG--
extra : moz-landing-system : lando
This adds both the role as well as calculation of the posinset, setsize, and level calculation if not provided by the author.
Differential Revision: https://phabricator.services.mozilla.com/D64590
--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
Eitan Isaacson
Narcis Beleuzu
Morgan Reschenberg
Razvan Maries
Emilio Cobos Álvarez
James Teh
Noemi Erli
Sylvestre Ledru
Bogdan Tara
Yura Zenevich
Coroiu Cristina
Aaron Klotz
Marco Zehe
Ricky Stewart
Botond Ballo
Mirko Brodesser
Jonathan Watt
Mike Hommey
Csoregi Natalia
Simon Giesecke
Daniel Varga
Brendan Dahl
Brindusan Cristian
Jean-Yves Avenard
Andreea Pavel
pbz
Stefan Hindli
aarushivij
Chris Peterson
Tim Nguyen
Eric Rahm
Christoph Kerschbaumer
Drew Willcoxon
Cosmin Sabou
Mihai Alexandru Michis
Ed Lee
Mark Banner
Thal
Andrew McCreight
Ciure Andrei