Both Provider and Handler need to release the interfaces in StaticIA2Data.
Therefore, move this into a common function to avoid duplication pain in future.
MozReview-Commit-ID: 7J4iuvDa8m2
--HG--
extra : rebase_source : 98c97b51c27c318ba987787518cfd70bda8967d4
We need to clean up the VARIANT and BSTRs in DynamicIA2Data in the handler as well.
We do this in two places:
1. Before reading a new payload (because we need to clean up the existing payload); and
2. When we're being destroyed.
MozReview-Commit-ID: GvO7csuxtwZ
--HG--
extra : rebase_source : 92cc9a64deddee07bbbc77e53117c15351816778
DynamicIA2Data contains several BSTRs that need to be freed with SysFreeString.
Previously, we just did a ZeroMemory without actually freeing them.
This cleanup code is placed in a header file so it can be used by AccessibleHandler as well.
MozReview-Commit-ID: 4SWuK9oMRYZ
--HG--
extra : rebase_source : e7358752e7eee1bae000e4005832bfc48c9342af
If a client requests all text (via IAccessibleText::text with IA2_TEXT_OFFSET_LENGTH), it's quite likely they will want all other information about the text as well; i.e. embedded objects and attributes.
Therefore, fetch all of this using a single cross-process call.
The text is immediately returned to the client.
The hyperlinks and attributes are cached for later return to the client when they call the appropriate methods.
They are only cached for one call; i.e. after the client retrieves them, the cache is dropped.
This makes memory management simpler and lowers the risk of cache invalidation problems.
MozReview-Commit-ID: FgFkX8J7wg1
--HG--
extra : rebase_source : e521d6ca7b00fcf1aad1f0ada299bac4c4b85c50
This allows the handler to fetch all text information in a single cross-process call when appropriate.
Normally, it would be a minimum of 3 calls, plus one call for each additional attribute run.
MozReview-Commit-ID: K5x9bAWiWWJ
--HG--
extra : rebase_source : fbf89ff79d7afcff6bcc32ff940f9e06c1e7f136
We want to be able to cache data related to both IAccessibleText and IAccessibleHypertext2 in a single call.
This is difficult with the tearoff because separate instances of the tearoff get created for the two interfaces.
Ensuring we use the same instance means working around reference cycles.
We could maintain a separate cache object, but that makes things more complex.
Therefore, it's much simpler to get rid of the tearoff.
A few things to note:
1. ResolveAccHypertext has been renamed to ResolveIAHypertext for consistency with the rest of AccessibleHandler.
2. mAccHypertextProxy has been renamed to mIAHypertextPassThru for consistency with the rest of AccessibleHandler.
3. mIAHypertextPassThru is a weak reference (just like the rest of the passthru pointers) because it refers to a proxy interface and the proxy aggregates the handler.
Thus, we release it immediately to avoid reference cycles.
When it was a tearoff, this was not the case; it was a strong reference.
MozReview-Commit-ID: 8NwPA0T1MFX
--HG--
extra : rebase_source : 57c4d19516d01b820bb3b4c1a9974ff3b889ed64
As per the spec, if there are no hyperlinks, the hyperlinks array should be set to null and S_FALSE should be returned.
This saves pointless memory management when there are no hyperlinks.
MozReview-Commit-ID: 9wsiXBely6G
--HG--
extra : rebase_source : bc1f6b8a04205939b322393674414365fd89f39a
Key accessibility off of the tag name instead of the role attribute
and load styles in global.css instead of <resources>
MozReview-Commit-ID: Epv0rHHzbz0
--HG--
extra : rebase_source : 2239c8ccca8d899b4c4144faab7212f120f00e23
1. Bug 1363595 added support for retrieving accDefaultAction from the cache, but the value was never cached in the first place.
This would have meant that accDefaultAction was returning nothing to clients.
2. Since accDefaultAction is the name of the first action, we can also use this cached value for IAccessibleAction::name for index 0.
MozReview-Commit-ID: 6PGRH45kKdB
--HG--
extra : rebase_source : 52688f1e44ad7613c5dd14903b6240a51aa2d4eb
The handler's implementation of IAHyperlink just forwards calls through to the proxy.
However, it exists because we want the cache to be used when a hyperlink is retrieved.
When querying from the handler to IAHyperlink, we should use the same implementation.
This is mostly about consistency/correctness, especially as we're increasing complexity.
MozReview-Commit-ID: AwYibrFzUyf
--HG--
extra : rebase_source : 3d8f33639190a4220a21d0a6eeac401829d8345c
The proxy manager caches interfaces marshaled in the payload and returns them on QI without a cross-process call.
However, it doesn't know about interfaces which don't exist.
We can determine this from the payload, since interfaces which don't exist will have a null pointer.
We use this information to avoid querying the proxy in this case.
MozReview-Commit-ID: FnzDetmTiPP
--HG--
extra : rebase_source : 076ce714a69d3883a149487e5f9235ff495eedd0
Now that virtual buffers have to render across processes, we want to eliminate as many cross-process calls as possible.
This includes QueryInterface calls, since buffers query for several interfaces on every node they visit.
To avoid these cross-process QI calls, we include interfaces clients are likely to request in the handler payload.
This way, they get marshaled in the single call used to retrieve the object.
This patch does the following:
1. Passes the interceptor when building the payload.
We need this so we can get interceptors for other interfaces.
2. Splits the payload into two main parts: a static part and a dynamic part.
The (new) static part contains the interface pointers. The dynamic part contains the rest.
This is necessary because the refresh call cannot pass the interceptor, but the interceptor is needed to build the static part.
Also, re-building the static part is pointless when refreshing.
3. Includes the interface pointers in the payload (BuildStaticIA2Data).
The pointers also have to be cleaned up after marshaling.
4. Releases the interface pointers in the handler after the payload is received.
We do this because they're aggregated by the proxy manager as they're unmarshaled.
MozReview-Commit-ID: 6VRLMNScgwW
--HG--
extra : rebase_source : 249589643b7a69e870962ea55a44849bf03a2693
Reorder DocAccessibleParent's and DocAccessibleChild's constructor initializer lists to fix these VS2017 warnings:
a11y/DocAccessibleParent.h(32): warning C5038: data member 'mozilla::a11y::DocAccessibleParent::mShutdown' will be initialized after data member 'mozilla::a11y::DocAccessibleParent::mEmulatedWindowHandle'
accessible/ipc/win/DocAccessibleChild.cpp(22): warning C5038: data member 'mozilla::a11y::DocAccessibleChild::mEmulatedWindowHandle' will be initialized after data member 'mozilla::a11y::DocAccessibleChild::mIsRemoteConstructed'
MozReview-Commit-ID: 8flWtpe13ob
--HG--
extra : rebase_source : 96528a886c099897df691623948d755eecda119f