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 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
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
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
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
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
Please note that it is the first reformat with clang-format 9
I only saw a fix in the .mm file
# ignore-this-changeset
Differential Revision: https://phabricator.services.mozilla.com/D49056
--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
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
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
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
The conversion for "regular" <tabs> elements is straightforward, most of
the work here is to support the tab strip (the <tabs> element with the id
"tabbrowser-tabs"). The markup needed for the tab strip moves directly
into browser.xhtml and the construction/teardown logic is now explicitly
driven from gBrowser. There are many more little tweaks too numerous to
enumerate.
Differential Revision: https://phabricator.services.mozilla.com/D32855
--HG--
rename : browser/base/content/tabbrowser.xml => browser/base/content/tabbrowser-tabs.js
extra : source : c163881a80c9a032b40f7d965fad6a6850fcf8a4
extra : intermediate-source : a5c6deeda8a9475ac0268a4351417c8ff659c962
extra : histedit_source : 5eb8b3d14027f2aeca5c52534096837cd0343104%2Ca23a07ddd5e1fb8bd084644dd6db0ee028b7c4b4
The conversion for "regular" <tabs> elements is straightforward, most of
the work here is to support the tab strip (the <tabs> element with the id
"tabbrowser-tabs"). The markup needed for the tab strip moves directly
into browser.xhtml and the construction/teardown logic is now explicitly
driven from gBrowser. There are many more little tweaks too numerous to
enumerate.
Differential Revision: https://phabricator.services.mozilla.com/D32855
--HG--
rename : browser/base/content/tabbrowser.xml => browser/base/content/tabbrowser-tabs.js
extra : rebase_source : 6b2b0ed9b01958d1b2db605ab300c4bebcaa461c
extra : source : c163881a80c9a032b40f7d965fad6a6850fcf8a4
This patch marks `ScrollContentIntoView()` as `MOZ_CAN_RUN_SCRIPT` and changing
some callers of them to guarantee thar their parent callers are also safe.
Additionally, this patch moves it from `nsIPresShell` to `PresShell` because
all callers can refer `PresShell` directly.
Unfortunately, this patch changes a lot of methods in autocomplete and satchel
since this patch needs to mark some interface methods as `can_run_script` and
they are called each other. This means that autocomplete module is really
sensitive like editor module. Perhaps, autocomplete and satchel should do
scroll asynchronously and unmark some of them as `MOZ_CAN_RUN_SCRIPT` again.
Differential Revision: https://phabricator.services.mozilla.com/D28320
--HG--
extra : moz-landing-system : lando
This patch marks some methods of nsCoreUtils which are found at writing the
following patches, as `MOZ_CAN_RUN_SCRIPT`.
Due to bug 1543294, some of them are marked as `MOZ_CAN_RUN_SCRIPT_BOUNDARY`
because `MOZ_CAN_RUN_SCRIPT` requires to change base class, but that's
other licenses header or used in our code too many places.
Differential Revision: https://phabricator.services.mozilla.com/D26926
--HG--
extra : moz-landing-system : lando
A lot of files include `nsIPresShell.h` even though currently they don't
need it. This patch removes the unnecessary inclusions.
Differential Revision: https://phabricator.services.mozilla.com/D25744
--HG--
extra : moz-landing-system : lando
A lot of files include `nsIPresShell.h` even though currently they don't
need it. This patch removes the unnecessary inclusions.
Differential Revision: https://phabricator.services.mozilla.com/D25744
--HG--
extra : moz-landing-system : lando
`nsPresContext` should use `mozilla::PresShell` directly instead of
`nsIPresShell`. This patch makes it.
Unfortunately, `nsPresContext` and `nsIFrame` have `PresShell()`. Therefore,
we cannot use `PresShell*` in its methods so that this patch uses `mozilla::`
namespace prefix.
It might be better to rename them as `PresShellPtr()` in another bug.
Differential Revision: https://phabricator.services.mozilla.com/D25721
--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
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 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
Simply decouple the check for the checked attribute from the one for the type attribute.
Differential Revision: https://phabricator.services.mozilla.com/D12632
--HG--
extra : moz-landing-system : lando
Simon Giesecke
Emilio Cobos Álvarez
James Teh
Jonathan Watt
Tim Nguyen
Eitan Isaacson
Gabriele Svelto
Sylvestre Ledru
Morgan Reschenberg
Alexander Surkov
Coroiu Cristina
Mike Hommey
Boris Zbarsky
Andrew Swan
Ciure Andrei
Masayuki Nakano
Brian Grinstead
Dorel Luca
Razvan Maries
Neil Deakin
Ehsan Akhgari
Paolo Amadini
Marco Zehe