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
Mark the html:mark element to the new ROLE_MARK, which currently maps the same as role_text, and the xml-role of "mark", make sure we expose the roleDescription on Mac, and adjust the test so it tests that the attributes don't pick up any unexpected color for this particular element. So, the background attribute is empty when there is no unexpected, non-default background color.
Differential Revision: https://phabricator.services.mozilla.com/D52989
--HG--
extra : moz-landing-system : lando
1. When creating a DocAccessibleParent for an embedded document in an OOP iframe, it's possible that the embedder accessible hasn't been set yet.
This can occur if the iframe is initially hidden.
Previously, we incorrectly set the document up as a top level document (e.g. tab document) in this case.
Now, we set up the document as top level in its content process, set up the proxy, etc.
The document will be added to its child document later when the embedder is set.
2. When setting the embedder accessible for an OOP iframe, check if the embedded DocAccessibleParent already exists.
This can happen if an iframe is hidden and then shown or an iframe is reflowed by layout.
If it already exists, add the embedded (child) document to its embedder.
3. Mac's implementation of ProxyCreated requires that AddChildDoc be called *before* ProxyCreated so it can invalidate the native children of the parent.
Because it's possible for an OOP iframe document to be added to its embedder after the document is created, we can't satisfy this requirement for OOP iframe documents.
Therefore, we now allow a null parent in Mac's ProxyCreated and use the reorder event fired later to invalidate the native children.
Differential Revision: https://phabricator.services.mozilla.com/D51357
--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
This patch makes accessible module use `mozilla::PresShell` directly rather
than via `nsIPresShell`. Additionally, renames `DocAccessible::PresShell()`
to `DocAccessible::PresShellPtr()` for avoiding conflict with using
`PresShell` in it and its sub classes.
Differential Revision: https://phabricator.services.mozilla.com/D26663
--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.
This is a best effort attempt at ensuring that the adverse impact of
reformatting the entire tree over the comments would be minimal. I've used a
combination of strategies including disabling of formatting, some manual
formatting and some changes to formatting to work around some clang-format
limitations.
Differential Revision: https://phabricator.services.mozilla.com/D13046
--HG--
extra : moz-landing-system : lando
IA2 now has IA2_ROLE_CONTENT_INSERTION/DELETION.
Mac has AXInsert/DeleteStyleGroup subroles.
We now create accessibles for these elements and expose the appropriate role.
For ATK, there is no specific role for these, so we just use the generic ATK_ROLE_SECTION.
MozReview-Commit-ID: 2khzRa7BQ6z
--HG--
extra : rebase_source : e1c84bdef9a23b225e9870660050790df94c4beb
This patch is an automatic replacement of s/NS_NOTREACHED/MOZ_ASSERT_UNREACHABLE/. Reindenting long lines and whitespace fixups follow in patch 6b.
MozReview-Commit-ID: 5UQVHElSpCr
--HG--
extra : rebase_source : 4c1b2fc32b269342f07639266b64941e2270e9c4
extra : source : 907543f6eae716f23a6de52b1ffb1c82908d158a
And likewise for AttrCharacteristics::attributeName.
MozReview-Commit-ID: DwGzWCCKcVP
--HG--
extra : rebase_source : ac595af0b0da2cee36b5aecf4474880fbe993f11
Gecko has two document roles: roles::DOCUMENT_FRAME and roles::DOCUMENT.
However, the former was not being used at all; the latter was being used
for both ARIA documents and for the native document container. We can
therefore fix this issue by repurposing the unused internal role:
* Rename the role from roles::DOCUMENT_FRAME to roles::NON_NATIVE_DOCUMENT,
and add clarification to the doc strings in Role.h
* Ensure load events are still emitted for ARIA documents (bug 759833)
* Update the ARIA-document mochitests to reflect the above changes
* Change the ATK role mapping for roles::DOCUMENT (the native container)
from ATK_ROLE_DOCUMENT_FRAME TO ATK_ROLE_DOCUMENT_WEB.
* On IAccessible2, map roles::NON_NATIVE_DOCUMENT to ROLE_SYSTEM_DOCUMENT.
This should cause there to be no change in behavior for that platform.
* On macOS map roles::NON_NATIVE_DOCUMENT to NSAccessibilityGroupRole
with a subrole of AXDocument.
--HG--
extra : rebase_source : bb6bacfa08c0d22e4e52a25d309d15b2a913320d
(Path is actually r=froydnj.)
Bug 1400459 devirtualized nsIAtom so that it is no longer a subclass of
nsISupports. This means that nsAtom is now a better name for it than nsIAtom.
MozReview-Commit-ID: 91U22X2NydP
--HG--
rename : xpcom/ds/nsIAtom.h => xpcom/ds/nsAtom.h
extra : rebase_source : ac3e904a21b8b48e74534fff964f1623ee937c67
We should not be declaring forward declarations for nsString classes directly,
instead we should use nsStringFwd.h. This will make changing the underlying
types easier.
--HG--
extra : rebase_source : b2c7554e8632f078167ff2f609392e63a136c299
Perform a sanity check in Accessible::ARIATransformRole() for the
internal REGION role: If there is no accessible name, transform
the ARIA role into the native host language role. Also perform
a sanity check when getting the AXSubrole in macOS: If the roleAtom
is nsGkAtoms::region, only return AXLandmarkRegion if the internal
role is REGION.
Create a new internal REGION role which maps to the generic landmark role
of each platform accessibility API. Update the internal mapping of region
from roles::PANE and kGenericAccType to roles::REGION and eLandmark. Also
change the AXSubrole of region from "AXDocumentRegion" to "AXLandmarkRegion",
the latter being what is specified in the Core AAM 1.1 and used in Safari.
Add orientation() method to the macOS accessibility wrapper, mapping
states::Horizontal to NSAccessibilityHorizontalOrientationValue,
states::NSAccessibilityVerticalOrientationValue and the absence of
both to NSAccessibilityUnknownOrientationValue.
DPub ARIA AXLandmarkRegion-maped roles should have an AXRoleDescription
value of "region"; not "group." This requires an explicit mapping, which
was not done during the initial implementation. No new test cases because
we currently have no means to test platform-accessibility-API mappngs via
mochitest.
According to the Core Accessibility API Mappings 1.1 spec, on macOS,
the separator role should have AXRoleDescription "splitter" and no
subrole. The incorrect AXRoleDescription is due to the subrole mapping
to AXContentSeparator. Thus removing the latter fixes the former.
This removes the unnecessary setting of c-basic-offset from all
python-mode files.
This was automatically generated using
perl -pi -e 's/; *c-basic-offset: *[0-9]+//'
... on the affected files.
The bulk of these files are moz.build files but there a few others as
well.
MozReview-Commit-ID: 2pPf3DEiZqx
--HG--
extra : rebase_source : 0a7dcac80b924174a2c429b093791148ea6ac204