Elements such as html:span are normally only made accessible with ARIA attributes. Also expose them if they have a title attribute set. It can be assumed that information should be conveyed to the user in such cases.
Differential Revision: https://phabricator.services.mozilla.com/D17227
--HG--
extra : moz-landing-system : lando
Previously, we were always returning VT_UNKNOWN and an IEnumVARIANT.
According to the IAccessible documentation, this should only be done for multiple selection.
Change this to correctly return VT_EMPTY for no selection and VT_DISPATCH (with an accessible) for single selection.
Differential Revision: https://phabricator.services.mozilla.com/D17091
--HG--
extra : moz-landing-system : lando
This commit adds categories to all markers. This way the profiler's
marker categories and frame label categories agree. There are a few
duplicate category properties on some of the marker payloads, but
this could be cleaned up in a follow-up if needed.
Differential Revision: https://phabricator.services.mozilla.com/D16864
--HG--
extra : moz-landing-system : lando
Our accSelection implementation always returns an IUnknown which clients QI to IEnumVARIANT.
Marshaling as IUnknown works fine in this case, but it's more efficient and correct to marshal the correct interface.
Also, without this, we'd hit an assertion.
Depends on D16662
Differential Revision: https://phabricator.services.mozilla.com/D16663
--HG--
extra : moz-landing-system : lando
We only use the handler for specific interfaces such as IAccessible* and IAccessibleHyperlink.
For interfaces which don't use the handler, we currently write an empty payload, but this still adds bytes to the stream.
This seems to break marshaling such an interface in a VT_UNKNOWN in a VARIANT.
To fix this, just don't write any payload at all when we aren't using the handler for the target interface.
Differential Revision: https://phabricator.services.mozilla.com/D16662
--HG--
extra : moz-landing-system : lando
1. This requires exposing radiogroup's focusedItem property to C++.
Unfortunately, there's no existing equivalent in nsIDOMXULSelectControlItemElement.
radiogroup is the only element that needs this, so a new interface has been created for it.
2. Accessibility uses focusedItem instead of selectedItem when setting focus.
3. When an item is focused, accessibility needs to be notified.
This is done using a DOMMenuItemActive event.
Differential Revision: https://phabricator.services.mozilla.com/D15295
--HG--
extra : moz-landing-system : lando
Previously, if we had children a, b, c, and d, then removed b, the group position for c and d would potentially be marked as dirty, but a would not. This caused the check for the availability of previous group info to return outdated information.
This patch now always forces the update of all children's group position when a children move has occurred, since it potentially affects all the children, not just the ones after it. In addition, accGroupInfo::Update() now checks if the previous and next siblings that are being used as shortcuts have dirty group info, and are being used only if they do not.
Differential Revision: https://phabricator.services.mozilla.com/D16059
--HG--
extra : moz-landing-system : lando
This converts the tabmodalprompt binding to a class, to be constructed along side with the element
by TabModalPromptBox.
TabModalPromptBox will keep the instances in a map and pass it to the callers, instead of the element.
The tests and callers can access the class instance by passing the element reference to the map.
Differential Revision: https://phabricator.services.mozilla.com/D15505
--HG--
rename : toolkit/components/prompts/content/tabprompts.xml => toolkit/components/prompts/content/tabprompts.jsm
extra : moz-landing-system : lando
Summary: Really sorry for the size of the patch. It's mostly automatic
s/nsIDocument/Document/ but I had to fix up in a bunch of places manually to
add the right namespacing and such.
Overall it's not a very interesting patch I think.
nsDocument.cpp turns into Document.cpp, nsIDocument.h into Document.h and
nsIDocumentInlines.h into DocumentInlines.h.
I also changed a bunch of nsCOMPtr usage to RefPtr, but not all of it.
While fixing up some of the bits I also removed some unneeded OwnerDoc() null
checks and such, but I didn't do anything riskier than that.
In order to support IA2 live regions with e10s (bug 1322532), text change events sent from the child process to the parent process use sync IPC.
That comes at a slight performance cost: the content process is blocked until the parent returns from sending and handling the event.
However, there is no reason to do this if the event is not for an accessible inside a live region; current clients don't need the sync behaviour outside of live regions.
Differential Revision: https://phabricator.services.mozilla.com/D15183
--HG--
extra : source : 415f827cb9ce211c48b0c6625e917582bc81fd3a
On mingw this causes IIDs to be defined in headers. Those definitions conflict with _i.c files that are included as well. Since we include _i.c anyway, INITGUID is simply not needed.
widl can't handle generating the typelib without explicit importlib() in this case. This should be fixed in widl as well, but using importlib() in this case looks right anyway.
Also add an IsElement check in GetElementFromPoint in the APZ code since I think
the element cast is unsound in presence of Shadow DOM.
Differential Revision: https://phabricator.services.mozilla.com/D14355
--HG--
extra : moz-landing-system : lando
In order to support IA2 live regions with e10s (bug 1322532), text change events sent from the child process to the parent process use sync IPC.
That comes at a slight performance cost: the content process is blocked until the parent returns from sending and handling the event.
However, there is no reason to do this if the event is not for an accessible inside a live region; current clients don't need the sync behaviour outside of live regions.
Differential Revision: https://phabricator.services.mozilla.com/D15183
--HG--
extra : moz-landing-system : lando
The default implementation of get_accKeyboardShortcut falls back to using the keyboard accelerator if an access key is not available. For XUL menu items, this is not appropriate since the accelerator gets exposed as part of the accessible name already.
The result was a double announcement of the keyboard accelerator on menu items that did not have an access key (underlined letter).
Differential Revision: https://phabricator.services.mozilla.com/D14533
--HG--
extra : moz-landing-system : lando
In bug 1507365, we introduced the ability of nested label children of toolbar buttons to provide the accessible name for a xul:toolbarbutton element. However, the XBL of xul:toolbarbutton causes the creation of a label accessible even if no xul:label child is present, and only the label attribute is being used. The nsIAccessibleText interface on such labels is, however, completely broken. This causes NVDA's mouse tracking, which always uses the deepest nested child, to fail. As a result, when hovering over Hamburger menu items, the announcement would be wrong, e. g., lag one behind the actual button the mouse is hovering over.
To fix this, we only accept xul:label children if they come from real XUL markup, not from the label attribute and the XBL creating the label. This means that some of the test changes from bug 1507365 have to be reverted to accommodate the new old behavior. But the new test for an actual label child still passes.
Differential Revision: https://phabricator.services.mozilla.com/D14469
--HG--
extra : moz-landing-system : lando
