In the next patch we want to add a method called
GetUnanimatedStyleContextForElementNoFlush but that's much too long. Instead it
seems better to just drop 'ForElement' from all these methods since it should be
fairly obvious we are getting the style context for an element given that the
first argument is an element.
MozReview-Commit-ID: JQKaEuCKV2F
--HG--
extra : rebase_source : 3ba51f3b00d1ec7bc91102629d9c0abb88992fef
MozReview-Commit-ID: HkiIgDQURtK
The a11y COM handler consists of two classes. AccessibleHandler is the one that
is actually interposed by COM between the client and the proxy. It implements
IAccessible2_3, IServiceProvider, and IProvideClassInfo. It is derived from
mscom::Handler which takes care of most of the COM boilerplate for handler
instantiation. AccessibleHandler must override a few virtual functions from
mscom::Handler:
* QueryHandlerInterface - mscom::Handler must implement the "real" QI. This is
the method that mscom::Handler uses to delegate to the implementer.
* ReadHandlerPayload - deserializing the payload. This uses
mscom::StructFromStream and the IA2Data_Decode function that was generated by
midl. It should essentially be the inverse of the serialization code in the
IHandlerProvider implementation inside Gecko.
* MarshalAs - identical to IHandlerProvider::MarshalAs
* GetHandlerPayloadSize and WriteHandlerPayload - it sucks that we have to
include these, but they are neccessary for the scenario when COM wants to
make a proxy of a proxy. When that happens, we need to get COM to serialize
the payload again; it isn't smart enough to recognize payloads in existing
proxies and copy them itself.
In order to reduce round trips, AccessibleHandler implements the most
sophisticated IA2 interface. This way the client has access to any of those
interfaces from IDispatch all the way down to IAccessible2_3 without needing to
incur additional round-trips to obtain them.
We also implement IServiceProvider so that a client may QueryService for an IA2
interface without needing to incur more round trips. In addition, we maintain
a list of service IDs that we definitely do not support, and handle those
locally instead of incurring an IPC round-trip.
We also implement IProvideClassInfo because NVDA's python code (and presumably
other ATs that use interpreted languages) supports using that interface to
assist its FFI library with resolution of our COM objects.
COM wraps each instance of an IAccessible* proxy with an AccessibleHandler
object. Proxies whose interfaces are not part of the IDispatch ... IAccessible2_3
hierarchy are not wrapped with handlers (though this might change in the future
if we need to expand coverage). AccessibleHandler implements IAccessible2_3 such
that, if we have cached data available for a particular IA2 method, we provide
that cached data to the client. Otherwise we pass on the request to the COM
proxy for retrieval via IPC.
The other class in the handler dll is AccessibleHandlerControl. This class
implements the IHandlerControl interface that is provided to IGeckoBackChannel.
Gecko dispatches cache invalidation events using this interface. This class
is a singleton within the handler dll and manages shared, handler-wide resources.
--HG--
extra : rebase_source : 4fc3910f789b0ed92c90655344ffb89f576ca5bd
MozReview-Commit-ID: GTQF3x1pBtX
A general outline of the COM handler (a.k.a. the "smart proxy"):
COM handlers are pieces of code that are loaded by the COM runtime along with
a proxy and are layered above that proxy. This enables the COM handler to
interpose itself between the caller and the proxy, thus providing the
opportunity for the handler to manipulate an interface's method calls before
those calls reach the proxy.
Handlers are regular COM components that live in DLLs and are declared in the
Windows registry. In order to allow for the specifying of a handler (and an
optional payload to be sent with the proxy), the mscom library allows its
clients to specify an implementation of the IHandlerProvider interface.
IHandlerProvider consists of 5 functions:
* GetHandler returns the CLSID of the component that should be loaded into
the COM client's process. If GetHandler returns a failure code, then no
handler is loaded.
* GetHandlerPayloadSize and WriteHandlerPayload are for obtaining the payload
data. These calls are made on a background thread but need to do their work
on the main thread. We declare the payload struct in IDL. MIDL generates two
functions, IA2Payload_Encode and IA2Payload_Decode, which are used by
mscom::StructToStream to read and write that struct to and from buffers.
* The a11y payload struct also includes an interface, IGeckoBackChannel, that
allows the handler to communicate directly with Gecko. IGeckoBackChannel
currently provides two methods: one to allow the handler to request fresh
cache information, and the other to provide Gecko with its IHandlerControl
interface.
* MarshalAs accepts an IID that specifies the interface that is about to be
proxied. We may want to send a more sophisticated proxy than the one that
is requested. The desired IID is returned by this function. In the case of
a11y interfaces, we should always return IAccessible2_3 if we are asked for
one of its parent interfaces. This allows us to eliminate round trips to
resolve more sophisticated interfaces later on.
* NewInstance, which is needed to ensure that all descendent proxies are also
imbued with the same handler code.
The main focus of this patch is as follows:
1. Provide an implementation of the IHandlerProvider interface;
2. Populate the handler payload (ie, the cache) with data;
3. Modify CreateHolderFromAccessible to specify the HandlerPayload object;
4. Receive the IHandlerControl interface from the handler DLL and move it
into the chrome process.
Some more information about IHandlerControl:
There is one IHandlerControl per handler DLL instance. It is the interface that
we call in Gecko when we need to dispatch an event to the handler. In order to
ensure that events are dispatched in the correct order, we need to dispatch
those events from the chrome main thread so that they occur in sequential order
with calls to NotifyWinEvent.
--HG--
extra : rebase_source : acb44dead7cc5488424720e1bf58862b7b30374f
unfortunately because creating a DocAccessibleParent is not atomic one can be
created by AllocPDocAccessible(), but then RecvPDocAccessibleConstructor() can
fail. If that happens we will call actor destroyed on the new
DocAccessibleParent, however because the constructor messaged failed it will
not have a wrapper. That means this assert does not necessarily hold.
The Manager is set by IPDL for remotely constructed objects but our DocAccessibleChilds are created on the child process side, so we need to assign a manager in the constructor so that we can find it when needed.
--HG--
extra : rebase_source : 8bf76534860ed73fbdc71df494130f6028400fa3
Its possible to coalesce away events such that the first two events in the
queue are reorder events where the second reorder can be coalesced with the
first. In that case there's no point in shuffling the list before removing
the second reorder event.
Really, there are only two cases we need to worry about. Either
IsSelectionCached(), and then our SelectionProperties has the data we want, or
not and then we have a non-null mSelCon which has the data we want.
Since we are now using cached selection state a lot more (instead of
initializing the editor whenever someone asks for selection state), we need to
actually update it more correctly when .value is set.
And since we now update the cached selection state for the case when .value has
been set (to point to the end of the text), we need to change
HTMLInputElement::HasCachedSelection to return false for that case. Otherwise
we will always do eager editor init on value set. We handle that by not doing
eager init if the cached selection is collapsed.
The web platform test changes test the "update on .value set" behavior. They
fail without this patch, pass with it.
MozReview-Commit-ID: DDU8U4MGb23
Really, there are only two cases we need to worry about. Either
IsSelectionCached(), and then our SelectionProperties has the data we want, or
not and then we have a non-null mSelCon which has the data we want.
Since we are now using cached selection state a lot more (instead of
initializing the editor whenever someone asks for selection state), we need to
actually update it more correctly when .value is set.
And since we now update the cached selection state for the case when .value has
been set (to point to the end of the text), we need to change
HTMLInputElement::HasCachedSelection to return false for that case. Otherwise
we will always do eager editor init on value set. We handle that by not doing
eager init if the cached selection is collapsed.
The web platform test changes test the "update on .value set" behavior. They
fail without this patch, pass with it.
MozReview-Commit-ID: DDU8U4MGb23
a BindChildDoc message can race with the parent process shutting down a tab.
The result of that is that RecvBindChildDoc() can be called on a
DocAccessibleParent that has already been shut down by the destruction of the
owning TabParent.
