This patch makes the following changes to the macros.
- Removes PROFILER_LABEL_FUNC. It's only suitable for use in functions outside
classes, due to PROFILER_FUNCTION_NAME not getting class names, and it was
mostly misused.
- Removes PROFILER_FUNCTION_NAME. It's no longer used, and __func__ is
universally available now anyway.
- Combines the first two string literal arguments of PROFILER_LABEL and
PROFILER_LABEL_DYNAMIC into a single argument. There was no good reason for
them to be separate, and it forced a '::' in the label, which isn't always
appropriate. Also, the meaning of the "name_space" argument was interpreted
in an interesting variety of ways.
- Adds an "AUTO_" prefix to PROFILER_LABEL and PROFILER_LABEL_DYNAMIC, to make
it clearer they construct RAII objects rather than just being function calls.
(I myself have screwed up the scoping because of this in the past.)
- Fills in the 'js::ProfileEntry::Category::' qualifier within the macro, so
the caller doesn't need to. This makes a *lot* more of the uses fit onto a
single line.
The patch also makes the following changes to the macro uses (beyond those
required by the changes described above).
- Fixes a bunch of labels that had gotten out of sync with the name of the
class and/or function that encloses them.
- Removes a useless PROFILER_LABEL use within a trivial scope in
EventStateManager::DispatchMouseOrPointerEvent(). It clearly wasn't serving
any useful purpose. It also serves as extra evidence that the AUTO_ prefix is
a good idea.
- Tweaks DecodePool::SyncRunIf{Preferred,Possible} so that the labelling is
done within them, instead of at their callsites, because that's a more
standard way of doing things.
--HG--
extra : rebase_source : 318d1bc6fc1425a94aacbf489dd46e4f83211de4
All the instances are converted as follows.
- nsSubstring --> nsAString
- nsCSubstring --> nsACString
--HG--
extra : rebase_source : cfd2238c52e3cb4d13e3bd5ddb80ba6584ab6d91
All the instances are converted as follows.
- nsAFlatString --> nsString
- nsAFlatCString --> nsCString
--HG--
extra : rebase_source : b37350642c58a85a08363df2e7c610873faa6e41
Move the object attribute exposure of states::HASPOPUP from the ATK wrapper
code to the shared accessibility code. Call UniversalStatesFor() rather than
State() for performance.
--HG--
extra : rebase_source : e31c2d00da302538a7f6962d8f4dfd148a7d877e
Add RelationType::CONTAINING_WINDOW to the RelationTypeMap. Note that
there is no implementation for this RelationType in place yet, but this
addition will fix off-by-one bugs when mapping newly-added relation types
to platform accessibility APIs.
Add the new-to-ATK relation types to the ATK headers we maintain and
map those relation types to the internal equivalents. No new tests
because we have sufficient coverage for the internal relations and
currently lack a means to test platform accessibility API exposure.
Change the mapping of states::HASPOPUP from kNone to ATK_STATE_HAS_POPUP.
No new test added because there is not yet support for testing platform
accessibility API mappings via mochitest.
--HG--
extra : rebase_source : bdf50704fa23db29ec5d5b3cdc0b51c8e6466215
In ARIA 1.1, aria-readonly became a supported property of switch,
menuitemcheckbox, menuitemradio, and radiogroup.
aria-checked is not, and has not been, a supported property of menuitem.
This property should only be supported on checkable subclasses of the
ARIA menuitem role, namely menuitemcheckbox and menuitemradio.
In ARIA 1.1, "undefined" was added as a possible value of aria-orientation,
and the default value for the combobox and treegrid roles. Therefore, remove
states::VERTICAL from the nsRoleMapEntry for these two roles and update the
associated mochitest expectations. The rest of the ARIA roles which support
aria-orientation have the correct defaults and test coverage.
MozReview-Commit-ID: A1lCqvbQYAF
There is no clean API-based solution to this, so instead I went grovelling
through the DCOM wire protocol and was able to write a function that converts
handler OBJREFs into standard OBJREFs.
See also:
https://msdn.microsoft.com/en-us/library/cc226801
--HG--
extra : rebase_source : a650055c4adda3a1d99262e47f2b463074c6b935
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.
MozReview-Commit-ID: LVML7EZaSYD
In non-e10s AccessibleWrap::HandleAccEvent, we special case our handling of
CARET_MOVED and FOCUS events with a call to UpdateSystemCaretFor. In e10s mode
we were not doing the same thing for proxied events sent from content. This
threw JAWS for a loop and presumably messes up other ATs as well.
This patch modifies the IPDL messages for these two events so that we may
send the caret rect along with the event, thus allowing us to update the
system caret for proxied events as well.
--HG--
extra : rebase_source : e1502c12b038739520afd5c7078d011e25ea669e
Here is a scenario under which the assert is invalid:
RecvHideEvent is received on a DocAccessibleParent DAP1 that has a child document DAP2... that in turn has a child document DAP3. DAP1::RecvHideEvent calls Shutdown on its root ProxyAccessible. This recursively calls Shutdown on child ProxyAccessibles until it reaches the one that is the parent of the child document DAP2. ProxyAccessibleBase::Shutdown then attempts to Unbind DAP2, which calls DAP1::RemoveChildDoc, which trips the assert because DAP2 has child document DAP3.
In content processes, we want to avoid a situation where a DocAccessible has lost its IPC actor (DocAccessibleChild) but finds itself processing a delayed request to take on child documents. In this case, we shut down the child documents as they are no longer valid.
Now that we inherit the recommended configurations, many definitions are handled semi-automatically.
MozReview-Commit-ID: 1H2MXzk6VdQ
--HG--
extra : rebase_source : 25e9e8b9a9f62d4e22873998ff4532fbcbe2e367
It is awkward to need to have a DocAccessibleChild to send events with before
DocAccessible::DoInitialUpdate() is called because we might not have a
TabParent for the document until then. However we could try to fire reload
events on documents before DoInitialUpdate() was called which would require
having a DocAccessibleChild there to send the load event to the parent process.
However before DocAccessible::DoInitialUpdate() is called the document already
has a pending load event. If a document hasn't yet been the subject of a load
event it doesn't make a lot of sense to fire a reload event for that document,
and then the initial load event. So it should be safe to skip firing
reload events for documents where mLoadEvent specifies a load event to
fire in the future.
We sometimes briefly have more than one root DocAccessible associated with a TabChild, for example, while navigating links in a page. This patch makes sure that we use the correct accessible when delaying messages that we forward to the parent process.
This avoids conflicts with mozilla::dom::FrameType.
MozReview-Commit-ID: 7aEMbHRaTFk
--HG--
extra : rebase_source : 2d01321f5ce0ec8c0e3f70984674f82678034b3c
Joanmarie Diggs
Bill McCloskey
Masatoshi Kimura
Aaron Klotz
Eitan Isaacson
Florian Quèze
Nicholas Nethercote
Carsten "Tomcat" Book
Wes Kocher
Rajesh Kathiriya
Sebastian Hengst
Ryan VanderMeulen
Jim Mathies
Mark Banner
Jan de Mooij
Marco Zehe
Mats Palmgren
Christoph Kerschbaumer
dbolter
Dan Banner
tiago
David Parks
Alexander Surkov
Tom Tromey
Trevor Saunders
Emilio Cobos Álvarez