Lazily creating children might cause us to make layout calls at unsafe times.
Differential Revision: https://phabricator.services.mozilla.com/D47361
--HG--
extra : moz-landing-system : lando
For remote content documents, select dropdowns (for <select size="1">) are rendered in the parent process using a XUL menupopup.
This means that the accessibility code for HTML selects doesn't apply.
In the menupopup, the optgroup is a sibling of its contained options.
For accessibility, we want to preserve the hierarchy such that the options are inside the optgroup.
We do this using aria-owns on the optgroup item.
This required some tweaks to XULMenuitemAccessible, as it couldn't previously handle grouping Accessibles between the menupopup and its items.
Differential Revision: https://phabricator.services.mozilla.com/D43901
--HG--
extra : moz-landing-system : lando
This is an extension protocol that can be used for platform specific
API (ie. AccessibleWrap methods).
I'm not thrilled with the seperate constructor for the sub-protocol.
This means that the parent won't have the actor upon DocAccessibleParent
construction, and some timing bugs can arise because of the extra round
trip. It would be cool if both actors could be co-created, but that
would require ManagedEndpoint, and for PBrowser to manage them both. I
don't want to expose this to PBrowser.
Differential Revision: https://phabricator.services.mozilla.com/D37955
--HG--
extra : moz-landing-system : lando
And also this patch moves `TextEditRules::HandleNewLines()` and
`TextEditRules::DontEchoPassword()` to `TextEditor`.
Differential Revision: https://phabricator.services.mozilla.com/D45298
--HG--
extra : moz-landing-system : lando
This is an extension protocol that can be used for platform specific
API (ie. AccessibleWrap methods).
I'm not thrilled with the seperate constructor for the sub-protocol.
This means that the parent won't have the actor upon DocAccessibleParent
construction, and some timing bugs can arise because of the extra round
trip. It would be cool if both actors could be co-created, but that
would require ManagedEndpoint, and for PBrowser to manage them both. I
don't want to expose this to PBrowser.
Differential Revision: https://phabricator.services.mozilla.com/D37955
--HG--
extra : moz-landing-system : lando
This is an extension protocol that can be used for platform specific
API (ie. AccessibleWrap methods).
I'm not thrilled with the seperate constructor for the sub-protocol.
This means that the parent won't have the actor upon DocAccessibleParent
construction, and some timing bugs can arise because of the extra round
trip. It would be cool if both actors could be co-created, but that
would require ManagedEndpoint, and for PBrowser to manage them both. I
don't want to expose this to PBrowser.
Differential Revision: https://phabricator.services.mozilla.com/D37955
--HG--
extra : moz-landing-system : lando
Having a full VPATH for the srcdir sometimes causes make to grab the
wrong prerequisite for a rule, in particular if we have a file in the
srcdir and also generate a file of the same name in the objdir. We don't
really need VPATH anymore though, since most of the information comes
from mozbuild, where we can explicitly list the path to the srcdir or
objdir as necessary.
Differential Revision: https://phabricator.services.mozilla.com/D42968
--HG--
extra : moz-landing-system : lando
`WindowsErrorResult` is a class to hold either a value or a Windows error
code based on the `Result` template. We also have `LauncherResult` for the
same purpose, which was introduced as a part of the launcher process feature
afterward. The difference is `LauncherResult` holds a filename and line
number along with an error code.
This patch integrates LauncherResult.h into WinHeaderOnlyUtils.h so that we
can use `LauncherResult` more broadly.
Differential Revision: https://phabricator.services.mozilla.com/D44512
--HG--
extra : moz-landing-system : lando
This assures that a node that has already been inserted in a shadow root
subtree does not get erroneously reinserted into the top container.
Differential Revision: https://phabricator.services.mozilla.com/D44880
--HG--
extra : moz-landing-system : lando
focusChecker expects a unique focus event.
However, there might still be pending focus events not caught by previous tests.
Therefore, we specify our own checker so we can disable the uniqueness requirement.
This is a little ugly, but it's rather difficult to work around this within this declarative framework without potentially breaking other tests.
Differential Revision: https://phabricator.services.mozilla.com/D44615
--HG--
extra : moz-landing-system : lando
Pruning these meant that `<span><br></span>` wasn't represented in the tree or rendered text at all.
This meant that lines were merged together in NVDA browse mode; e.g. in CI build logs on Gitlab.
The reason we started pruning these is that they were causing invalid line offsets to be returned for affected lines (bug 899433).
This patch also fixes this problem in HyperTextAccessible::FindOffset.
Differential Revision: https://phabricator.services.mozilla.com/D44815
--HG--
extra : moz-landing-system : lando
All calls to `profiler_add_marker()` (outside of the profilers code) are
now replaced by either:
- `PROFILER_ADD_MARKER(name, categoryPair)`
- `PROFILER_ADD_MARKER_WITH_PAYLOAD(name, categoryPair, TypeOfMarkerPayload,
(payload, ..., arguments))`
This makes all calls consistent, and they won't need to prefix the category pair
with `JS::ProfilingCategoryPair::`.
Also it will make it easier to add (and later remove) internal-profiling
instrumentation (bug 1576550), and to replace heap-allocated payloads with
stack-allocated ones (bug 1576555).
Differential Revision: https://phabricator.services.mozilla.com/D43588
--HG--
extra : moz-landing-system : lando
For labels inside buttons, The base implementation of DispatchClickEvent doesn't fire a command event on the button.
To fix this, override DispatchClickEvent to use nsXULElement::Click, which does fire a command event on the button.
Differential Revision: https://phabricator.services.mozilla.com/D44410
--HG--
extra : moz-landing-system : lando
For OOP iframes, sometimes, AddChildDoc gets called before the embedder sends us the OuterDocAccessible.
Previously, we crashed when this occurred.
Now, we add the child when the OuterDocAccessible proxy gets created later.
Differential Revision: https://phabricator.services.mozilla.com/D42798
--HG--
extra : moz-landing-system : lando
We have an optimization to avoid an expensive reflow from SetFullZoom, see
mSuppressResizeReflow[1].
That was done because we used to do a full synchronous reflow right after. We no
longer do that, but due to that member we also don't invalidate!
My second patch in this bug changes the behavior of that flag so that we don't
synchronously reflow, but we do invalidate. So in turn this test before the
change wasn't really testing the zoomed code-path since it was using the clean
layout from before the zoom operation.
a11y getBounds and co. don't flush layout (they probably should), but since with
my patch we dirty the frame tree, and dirty frames return bogus offsets, the
test starts failing.
Flush layout explicitly to ensure we're testing the zoomed code path.
[1]: https://searchfox.org/mozilla-central/rev/325c1a707819602feff736f129cb36055ba6d94f/layout/base/nsPresContext.cpp#952
Differential Revision: https://phabricator.services.mozilla.com/D43952
--HG--
extra : moz-landing-system : lando
This patch does several things:
1. If there is a change to a host or a slot, check the slottable
elements to see if they are rendered in the tree. Remove them if not.
2. Check slot elements' fallback content if it is rendered and remove if
not.
3. Allow accessibles to be reinserted into a different parent or index.
Differential Revision: https://phabricator.services.mozilla.com/D43489
--HG--
extra : moz-landing-system : lando
Converts ui.key.generalAccessKey, ui.key.chromeAccess, and ui.key.contentAccess to static prefs. Updates usages.
Differential Revision: https://phabricator.services.mozilla.com/D42392
--HG--
extra : moz-landing-system : lando
performAction, performActionOnRow and performActionOnCell are methods of the
nsITreeView interface that are never called. This is to remove these methods.
A comm-central patch will be along shortly.
Differential Revision: https://phabricator.services.mozilla.com/D39273
I replaced the values with -moz-inline-box in the crashtests
rather than removing them. I think they are still valuable
after replacing the display value.
Differential Revision: https://phabricator.services.mozilla.com/D42551
--HG--
extra : moz-landing-system : lando
1. As per the spec, if maxTargets is 0, return all targets.
2. Where maxTargets > 0, fix the loop condition so it doesn't incorrectly fetch one more target than requested.
Differential Revision: https://phabricator.services.mozilla.com/D42446
--HG--
extra : moz-landing-system : lando
The DOM mutation observer method is called during frame destruction
which is not a good state to be in when constructing and dispatching events.
Differential Revision: https://phabricator.services.mozilla.com/D41825
--HG--
extra : moz-landing-system : lando
(This basically addresses the review comments that I missed in
bug 1105868 part 4. My bad.)
Differential Revision: https://phabricator.services.mozilla.com/D42134
--HG--
extra : moz-landing-system : lando
This change will bring us on par with what Chrome does. However, if the author makes an error in applying a landmark role to an interactive element, or other element where the landmark role is illegal, as defined in the [WAI-ARIA in HTML specification section 2](https://www.w3.org/TR/html-aria/#document-conformance-requirements-for-use-of-aria-attributes-in-html), the accessible properties will now be that of the landmark role, no longer that of the native host language element. This might make some elements less accessible due to author error than before, but we currently do not know of examples in the wild that actually expose this problem. This could only be solved by applying the rules from said table also in the user agents, but that is not specified anywhere.
Differential Revision: https://phabricator.services.mozilla.com/D41923
--HG--
extra : moz-landing-system : lando
For accessibility, the address bar is now exposed as a parent combo box which contains the input and the results list.
The combo box role on urlbarView-body-inner is no longer needed and has therefore been removed.
This means screen readers no longer report an extraneous combo box whenever the results list is opened.
Differential Revision: https://phabricator.services.mozilla.com/D40917
--HG--
extra : moz-landing-system : lando
All .xul files have been loading as HTMLDocuments for a few weeks now, so
it should be safe to remove the XULDocument implementation.
Differential Revision: https://phabricator.services.mozilla.com/D41238
--HG--
extra : moz-landing-system : lando
Removing an Accessible removes descendants in the a11y tree.
However, there may be DOM descendants which have been relocated elsewhere in the a11y tree.
Their DOM nodes are now hidden as well, so we need to remove those Accessibles too.
In addition to Accessibles remaining in the tree when they shouldn't, failing to remove relocated Accessibles caused problems later on when a relocated Accessible was shown with new descendants.
Differential Revision: https://phabricator.services.mozilla.com/D41178
--HG--
extra : moz-landing-system : lando
We need to visit the descendants of a container that has no accessible,
but has accessible children.
Also added a test for delayed removal where we can put all these nasty
cases.
Differential Revision: https://phabricator.services.mozilla.com/D41059
--HG--
extra : moz-landing-system : lando
For accessibility, the address bar is now exposed as a parent combo box which contains the input and the results list.
The combo box role on urlbarView-body-inner is no longer needed and has therefore been removed.
This means screen readers no longer report an extraneous combo box whenever the results list is opened.
Differential Revision: https://phabricator.services.mozilla.com/D40917
--HG--
extra : moz-landing-system : lando
The current test doesn't actually do anything because divs with IDs are
always created.
Differential Revision: https://phabricator.services.mozilla.com/D40674
--HG--
extra : moz-landing-system : lando
Previously, if a hidden, aria-owned subtree was shown and aria-activedescendant was simultaneously targeted inside it, aria-activedescendant would fail.
This occurred because when we processed insertions, the presence of aria-owns meant we didn't create the subtree.
This meant that when we processed aria-activedescendant (which occurred before relocations), the active descendant didn't exist yet.
To fix this, we now process generic notifications (including aria-activedescendant) *after* relocations.
Differential Revision: https://phabricator.services.mozilla.com/D40579
--HG--
extra : moz-landing-system : lando
Converts accessibility.AOM.enabled to static pref and removes the related mirror variable and static flag used to initially generate the varcache pref
Differential Revision: https://phabricator.services.mozilla.com/D40101
--HG--
extra : moz-landing-system : lando
Also reworked test_recreation.html to test/demo how these ergonomics
would work.
Differential Revision: https://phabricator.services.mozilla.com/D40124
--HG--
rename : accessible/tests/browser/events.js => accessible/tests/mochitest/promisified-events.js
extra : moz-landing-system : lando
We naively remove and then recreate accessibles when their content's
frame is reconstructed. By delaying the removal until we are certain the
content does not have a new layout frame, we can cut down on redundant
recreations.
When reconstructed content is re-inserted we can check it and its
subtree for missing frames and prune those accessibles from the tree.
Differential Revision: https://phabricator.services.mozilla.com/D38380
--HG--
extra : moz-landing-system : lando
This is the first step in making it possible to return remote WindowProxy
objects from window.open() and related APIs.
This patch also incidentally fixes a bug where getContentWindowOrOpenURI
returned the top-level browser window rather than the new content window when
passed OPEN_NEWWINDOW for the `aWhere` parameter. This was not the expected
behavior, and was a potentially major footgun for any new users who expected
to always get the content window for the URL they were loading, rather than
sometimes getting a chrome browser window instead.
For now, that case just returns null, which is only a minor footgun, rather
than the major one we had before.
Differential Revision: https://phabricator.services.mozilla.com/D35688
--HG--
extra : moz-landing-system : lando
Editor creates a `<br>` element when it's root element is empty.
Then, it's stored by `TextEditRules::mBogusNode` and used for checking
whether the editor is empty quickly. However, this `<br>` element has
`mozeditorbogusnode` attribute whose value is `true`. However, adding or
removing the attribute is not cheap and web apps can refer such illegal
attribute.
Therefore, this patch makes `HTMLBRElement` take a specific flag whether
it's a bogus node or not. However, this means that this hacky thing will be
exposed outside editor module. For making what is the bogus node clearer,
this patch calls the such `<br>` elements as "padding `<br>` element for
empty editor". So, this patch also includes a lot of renaming methods and
variables, and modifying related comments.
Differential Revision: https://phabricator.services.mozilla.com/D39857
--HG--
extra : moz-landing-system : lando
Normally, the OuterDocAccessible is created first and the DocAccessibleParent for a remote document is created after that.
So, we get the OuterDocAccessible and call DocAccessibleParent::SendParentCOMProxy when the DocAccessibleParent is constructed (BrowserParent::RecvPDocAccessibleConstructor).
However, sometimes, the OuterDocAccessible is created *after* the DocAccessibleParent.
This sometimes happens for extension popups, for example.
In that case, we previously never sent the parent COM proxy.
Aside from leaving the remote document with a null parent, this also meant we never sent any events for the document, since events are buffered for remote documents until the parent COM proxy is received.
This effectively left the remote document (e.g. extension popup) inaccessible.
Now, we also call SendParentCOMProxy in the OuterDocAccessible constructor.
Note that this doesn't result in duplicates because if the OuterDocAccessible was created first, there won't be a DocAccessibleParent for the remote document yet, so this code won't run.
That said, if the OuterDocAccessible is recreated (e.g. due to frame reconstruction), we may call SendParentCOMProxy again.
This should be okay, but it required an assertion in DocAccessibleChild::RecvParentCOMProxy to be tweaked.
Differential Revision: https://phabricator.services.mozilla.com/D40358
--HG--
extra : moz-landing-system : lando
Previously, we expected that we'd always be able to get the COM proxy for the parent (outer doc), so we crashed if it was null.
For an out-of-process iframe, this sometimes fails.
That is probably because the outer doc died in the embedder process, but the parent process hasn't received a message to remove it from the ProxyAccessible tree yet.
Differential Revision: https://phabricator.services.mozilla.com/D40150
--HG--
extra : moz-landing-system : lando
It seems a bit more sensible to me that if any filtering needs to happen
from content insertions, it should happen in the doc and not the
notification controller.
Differential Revision: https://phabricator.services.mozilla.com/D40132
--HG--
extra : moz-landing-system : lando
In FocusManager::ProcessFocusEvent, after firing the event, we get the anchor jump from the target Accessible's document.
However, it seems the Accessible can be shut down during the call to nsEventShell::FireEvent, resulting in a crash when we try to get the anchor jump.
Protect against this by checking whether the target is defunct after firing the event.
Differential Revision: https://phabricator.services.mozilla.com/D39450
--HG--
extra : moz-landing-system : lando
Previously, we would always calculate the name for tr elements from their descendants unconditionally. Assistive technologies aren't using this information, moreover, it causes problems if the name gets too long, for example in layout tables.
We now only calculate the name if the tr element has an explicit ARIA role.
Differential Revision: https://phabricator.services.mozilla.com/D39314
--HG--
extra : moz-landing-system : lando
This was an oversight in the checkin for bug 1461244. tfoot was duplicated due to a copy and paste error, thead was not mapped at all. It is now properly mapped, and the test adjusted accordingly.
Differential Revision: https://phabricator.services.mozilla.com/D39305
--HG--
extra : moz-landing-system : lando
Previously, the target element for aria-activedescendant was retrieved by calling GetElementById on the owner document.
This meant that aria-activedescendant inside shadow DOM looked for ids in the owner document instead of the shadow DOM.
To fix this, use IDRefsIterator::GetElem instead.
Differential Revision: https://phabricator.services.mozilla.com/D38833
--HG--
extra : moz-landing-system : lando
IDRefsIterator::GetElem was previously an instance method which could only be used if you instantiated IDRefsIterator.
This is overkill for attributes which can only take a single id reference (rather than an id reference list).
Now, there is a static version of IDRefsIterator::GetElem which can be called with an arbitrary source element.
Any accessibility code should henceforth be using this instead of calling GetElementById directly, as this deals with shadow DOM, etc.
Differential Revision: https://phabricator.services.mozilla.com/D38832
--HG--
extra : moz-landing-system : lando
On Windows, OuterDocAccessible::GetChildAt can return a proxy wrapper for a remote document.
These aren't real Accessibles and shouldn't be returned except to the Windows a11y code (which doesn't use eDeepestChild).
Calling ChildAtPoint on these will crash!
Therefore, just return null in this case.
Differential Revision: https://phabricator.services.mozilla.com/D39135
--HG--
extra : moz-landing-system : lando
In bug 1525101, autocomplete-richlistbox-popup was converted to a Custom Element.
This means we can no longer use do_QueryInterface to get nsIAutoCompletePopup.
Instead, we must use Element::AsAutoCompletePopup.
This fixes accessibility focus for these autocompletes.
Differential Revision: https://phabricator.services.mozilla.com/D38158
--HG--
extra : moz-landing-system : lando
OuterDocAccessible can return a DocProxyAccessibleWrap or RemoteIframeDocProxyAccessibleWrap as a child.
Accessible::ChildAtPoint on an ancestor might retrieve this proxy and call Bounds() on it.
This will crash on a proxy, so we override it on these document proxies to do nothing.
Differential Revision: https://phabricator.services.mozilla.com/D38256
--HG--
extra : moz-landing-system : lando
Alexander Surkov
Eitan Isaacson
James Teh
Morgan Reschenberg
Coroiu Cristina
Sean Feng
Andreea Pavel
Hiroyuki Ikezoe
Yura Zenevich
Tim Nguyen
Andrew Halberstadt
Noemi Erli
arthur.iakab
Dorel Luca
Kris Maglione
Edgar Chen
Daniel Varga
Jonathan Kew
Mihai Alexandru Michis
Masayuki Nakano
Dão Gottwald
Mike Shal
Toshihito Kikuchi
Gerald Squelart
Tom Ritter
Emilio Cobos Álvarez
Maliha Islam
kriswright
Alex Vincent
Gautham Velchuru
Mike Hommey
Olli Pettay
Samuel Thibault
Mats Palmgren
Marco Zehe
Brendan Dahl
Kannan Vijayan
Tom Schuster
Cosmin Sabou
Razvan Maries
Christian Holler
Boris Zbarsky