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
nsFocusManager::SetFocus (and thus Accessible::TakeFocus) was fixed for Fission in bug 1556627.
Most of these tests now pass without modification.
browser_caching_value.js needed to be tweaked slightly to synthesize a key in the OOP iframe instead of the top level document.
Differential Revision: https://phabricator.services.mozilla.com/D64254
--HG--
extra : moz-landing-system : lando
This covers most cycle collected objects which support weak references, but
not the ones which inherit from a cycle collected class and don't do any cycle
collection on their own.
Differential Revision: https://phabricator.services.mozilla.com/D63962
--HG--
extra : moz-landing-system : lando
In a somewhat easy way. There are better ways to do this (moving
text-decoration-style to be a proper cbindgen enum class or such), but this
does the job for now.
Depends on D63794
Differential Revision: https://phabricator.services.mozilla.com/D63795
--HG--
extra : moz-landing-system : lando
::marker content gets handled like text from any other CSS pseudo-class.
Therefore, using HTMLListBulletAccessible ends up duplicating the content already exposed in the a11y tree.
Now, we only use HTMLListBulletAccessible for nsBulletFrames instead of all marker frames.
As part of this, remove nsContainerFrame::GetSpokenMarkerContent, since we no longer need it to retrieve ::marker content.
The bulk of its other work was done by nsBulletFrame::GetSpokenContent, which we now call directly.
It also handled producing a default bullet character for list-style-image, but it makes sense for this to live in the a11y code.
Differential Revision: https://phabricator.services.mozilla.com/D63443
--HG--
extra : moz-landing-system : lando
If a keyboard-focused accessible is removed, the caret jumps to its
nearest ancestor. To avoid arbitrary accessibility focus moves, ignore
caret events that have no selection and are not focusable items.
Differential Revision: https://phabricator.services.mozilla.com/D63541
--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
GENERATED_FILES now defaults to python3 unless py2=True is specified as
an argument. All existing GENERATED_FILES scripts and GeneratedFile
templates have the py2=True attribute added, so this patch should
effectively be a no-op.
Going forward, individual scripts can be converted to python3 and their
corresponding py2=True attribute can be deleted. In effect, this patch
will be backed out in pieces until all scripts run in python3, at which
point the py2 attribute itself can be removed.
Differential Revision: https://phabricator.services.mozilla.com/D60919
--HG--
extra : moz-landing-system : lando
Normally, XUL menupopups contain XUL menuitems, and XUL menuitems fire DOMMenuitemActive events from layout to manage a11y focus.
However, the new parent process select dropdown implementation uses a menulist containing div elements instead of XUL menuitems.
DOMMenuItemActive doesn't work for div elements because we check Accessible::ContainerWidget(), and that doesn't know to return the menupopup for div elements.
Since aria-activedescendant is the more web standard way to handle this, the new select dropdown implementation uses aria-activedescendant.
Differential Revision: https://phabricator.services.mozilla.com/D62677
--HG--
extra : moz-landing-system : lando
Currently, only documents dispatch scroll events when in reality any
element can have scrollable overflows.
Differential Revision: https://phabricator.services.mozilla.com/D62665
--HG--
extra : moz-landing-system : lando
GENERATED_FILES now defaults to python3 unless py2=True is specified as
an argument. All existing GENERATED_FILES scripts and GeneratedFile
templates have the py2=True attribute added, so this patch should
effectively be a no-op.
Going forward, individual scripts can be converted to python3 and their
corresponding py2=True attribute can be deleted. In effect, this patch
will be backed out in pieces until all scripts run in python3, at which
point the py2 attribute itself can be removed.
Differential Revision: https://phabricator.services.mozilla.com/D60919
--HG--
extra : moz-landing-system : lando
GENERATED_FILES now defaults to python3 unless py2=True is specified as
an argument. All existing GENERATED_FILES scripts and GeneratedFile
templates have the py2=True attribute added, so this patch should
effectively be a no-op.
Going forward, individual scripts can be converted to python3 and their
corresponding py2=True attribute can be deleted. In effect, this patch
will be backed out in pieces until all scripts run in python3, at which
point the py2 attribute itself can be removed.
Differential Revision: https://phabricator.services.mozilla.com/D60919
--HG--
extra : moz-landing-system : lando
Chrome prunes the subtrees of links and headings (with single text leaf
children) and we mimic this in Gecko. The problem is that sometimes a
heading can be a child of a link, and it would be impossible to reach
when navigating by headings.
The main reason we mimiced chrome is because we would getthe name of the
node and its subtree uttered, so you would hear the name of the node
twice. By using contentDescription we can suppress the subtree from
TalkBack's utterance and preserve the node's children for heading
navigation.
Differential Revision: https://phabricator.services.mozilla.com/D61766
--HG--
extra : moz-landing-system : lando
We replace the a11y telemetry thread with a call to the new
`NS_DispatchBackgroundTask` infrastructure. We use `NS_DISPATCH_EVENT_MAY_BLOCK`
because the task performs some I/O to load the instantiator's version info.
I also took the opportunity to eliminate some redundant copying.
Differential Revision: https://phabricator.services.mozilla.com/D61769
--HG--
extra : moz-landing-system : lando
Added long press as well as the old tooltip language back
and updated 2 tests.
Differential Revision: https://phabricator.services.mozilla.com/D61717
--HG--
extra : moz-landing-system : lando
`nsRange` instances are allocated a lot in the heap especially by editor and
spellchecker. The allocation cost is too bad for benchmarks. Therefore,
we should reuse released instances as far as possible. For managing it in
static factory methods of `nsRange`, we need to hide `nsRange` constructor.
Differential Revision: https://phabricator.services.mozilla.com/D61237
--HG--
extra : moz-landing-system : lando
Added right click on new tab button to open containers menu.
Removed long press and added option to enable left click in preferences menu.
Renamed privacy.userContext.longPressBehavior to privacy.userContext.newTabContainer.enabled
Differential Revision: https://phabricator.services.mozilla.com/D58410
--HG--
extra : moz-landing-system : lando
This is just not a thing you can do if you have min() / max() / etc, as the min
/ max value may depend on the percentage basis.
Differential Revision: https://phabricator.services.mozilla.com/D60168
--HG--
extra : moz-landing-system : lando
This means that for any other ARIA role, we will expose the DOCUMENT role on the DocAccessible.
Differential Revision: https://phabricator.services.mozilla.com/D60632
--HG--
extra : moz-landing-system : lando
This is just not a thing you can do if you have min() / max() / etc, as the min
/ max value may depend on the percentage basis.
Differential Revision: https://phabricator.services.mozilla.com/D60168
--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
After bug 981248, <input type="number"> no longer has an anonymous text input.
Instead, the <input type="number"> itself manages the text.
Previously, the a11y code which fired value change events for text changes only did this for combo boxes and role ENTRY.
This meant a value change event was no longer fired for <input type="number">.
This condition has now been extended to include role SPINBUTTON.
This fixes reporting of <input type="number"> changes for JAWS.
Differential Revision: https://phabricator.services.mozilla.com/D60101
--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
Instead, subclass nsTextControlFrame. This simplifies the code and avoids
correctness issues.
I kept the localization functionality though it is not spec compliant. But I
filed a bug to remove it in a followup.
Differential Revision: https://phabricator.services.mozilla.com/D57193
--HG--
extra : moz-landing-system : lando
Instead, subclass nsTextControlFrame. This simplifies the code and avoids
correctness issues.
I kept the localization functionality though it is not spec compliant. But I
filed a bug to remove it in a followup.
Differential Revision: https://phabricator.services.mozilla.com/D57193
--HG--
extra : moz-landing-system : lando
Previously, when opening the dialog, we only waited for a reorder event.
This could mean we programmatically closed the dialog before it was ever focused.
That in turn would mean that focus would never be fired on the previous window when the dialog was closed, causing the close dialog test to time out.
Differential Revision: https://phabricator.services.mozilla.com/D59826
--HG--
extra : moz-landing-system : lando
This reverts the change I made in bug 1572811, and instead fixes a much
more narrow case when the inner table frame is mid-construction.
Differential Revision: https://phabricator.services.mozilla.com/D58570
--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
It is unexpected (see bug) that a -moz-box is affected by baseline alignment.
Make -moz-box be block-outside, and -moz-inline-box be inline-outside, instead
of the bespoke thing we have now.
This is more similar to everything else, and fixes the bug.
Differential Revision: https://phabricator.services.mozilla.com/D58726
--HG--
extra : moz-landing-system : lando
It is unexpected (see bug) that a -moz-box is affected by baseline alignment.
Make -moz-box be block-outside, and -moz-inline-box be inline-outside, instead
of the bespoke thing we have now.
This is more similar to everything else, and fixes the bug.
Differential Revision: https://phabricator.services.mozilla.com/D58726
--HG--
extra : moz-landing-system : lando
Talkback users expect that when you navigate past the end of the text in a node, Talkback will move into the next node and navigate there.
However, even though text navigation is async (client performs an action on the focused accessible and then waits for a text traversal event), firing a traversal event with a different accessible from the focused accessible is not supported by Talkback.
Firing a11y focus on the new node (as we did previously) doesn't fix this, but instead causes the entire node to be reported, among other weird behaviour.
1. Don't fire a11y focus for text traversal.
Aside from Talkback reporting the entire node, this was also confusing Talkback, causing it to try to navigate several times into the new node.
2. When navigating text, cache whether we're at either edge.
We do this because we need to be able to synchronously query whether we're at the edge, but we do navigation async.
Special handling is needed for words at the end because words don't include trailing space.
3. When performing a text navigation action, check if we're already at the edge using the cache described above.
If we are, synchronously return false, as Talkback expects.
Talkback will then move to the next/previous node itself and navigate the text there.
Differential Revision: https://phabricator.services.mozilla.com/D57926
--HG--
extra : moz-landing-system : lando
In a follow-up commit a new `ComparePoints` method with cleaner
arguments and return value will be added.
Differential Revision: https://phabricator.services.mozilla.com/D55295
--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
Sometimes, when running tests, fetching IDispatch for a remote IAccessible succeeds, but QueryInterface to IAccessible fails.
This is probably because the remote Accessible died between these two calls.
While we want to know about this in case of real problems in future, it usually doesn't indicate a problem, so make it a warning.
Differential Revision: https://phabricator.services.mozilla.com/D55404
--HG--
extra : moz-landing-system : lando
Initially this was going to be a simple cleanup: Remove some useless namespaces
here and there and so on, remove `using` statements from the header and so on.
But unfortunately, DOMIntersectionObserver.h (which is included in Element.h,
unnecessarily) ended up exposing `Element` unnamespaced to a lot of code, so I
had to fix that.
Differential Revision: https://phabricator.services.mozilla.com/D55316
--HG--
extra : moz-landing-system : lando
Eitan Isaacson
James Teh
Morgan Reschenberg
Ricky Stewart
Botond Ballo
Marco Zehe
Mirko Brodesser
Jonathan Watt
Mike Hommey
Csoregi Natalia
Simon Giesecke
Daniel Varga
Brendan Dahl
Brindusan Cristian
Jean-Yves Avenard
Emilio Cobos Álvarez
Andreea Pavel
Noemi Erli
pbz
Stefan Hindli
aarushivij
Yura Zenevich
Chris Peterson
Tim Nguyen
Sylvestre Ledru
Eric Rahm
Christoph Kerschbaumer
Drew Willcoxon
Razvan Maries
Cosmin Sabou
Mihai Alexandru Michis
Ed Lee
Mark Banner
Thal
Andrew McCreight
Ciure Andrei
Kris Maglione
Arthur Iakab
Dorel Luca
Mike Shal
Aaron Klotz
Kendall Werts
Boris Zbarsky
Masayuki Nakano
Kendall Werts
Colomban Wendling
David Major
Alexander Surkov
Bogdan Tara
Hiroyuki Ikezoe
Kirk Steuber
Kannan Vijayan
Gabriele Svelto