This was done automatically replacing:
s/mozilla::Move/std::move/
s/ Move(/ std::move(/
s/(Move(/(std::move(/
Removing the 'using mozilla::Move;' lines.
And then with a few manual fixups, see the bug for the split series..
MozReview-Commit-ID: Jxze3adipUh
Because Interceptors disable COM garbage collection to improve performance, they never receive Release calls from remote clients.
If the object can be shut down while clients still hold a reference, this function can be used to force COM to disconnect all remote connections (using CoDisconnectObject) and thus release the associated references to the Interceptor, its target and any objects associated with the HandlerProvider.
A HandlerProvider::DisconnectHandlerRemotes method also had to be added to allow HandlerProviders to disconnect clients for their own objects.
MozReview-Commit-ID: JaxEkOtrP1M
--HG--
extra : rebase_source : bc7a4ab79458eaaddcef8df74ff4d6f685fbfdce
extra : histedit_source : 087f17f09a0c0e1c8e3b5f6d9690f331c15f0b95
COM queries for special interfaces such as IFastRundown when creating a marshaler.
We don't want these being dispatched to the main thread, since this would cause a deadlock on mStdMarshalMutex if the main thread is also querying for IMarshal.
MozReview-Commit-ID: EQcN8Zhewjh
--HG--
extra : rebase_source : 40c39edce139f66fdb43b539b1d6fb0acb00d755
Because Interceptors disable COM garbage collection to improve performance, they never receive Release calls from remote clients.
If the object can be shut down while clients still hold a reference, this function can be used to force COM to disconnect all remote connections (using CoDisconnectObject) and thus release the associated references to the Interceptor, its target and any objects associated with the HandlerProvider.
A HandlerProvider::DisconnectHandlerRemotes method also had to be added to allow HandlerProviders to disconnect clients for their own objects.
MozReview-Commit-ID: JaxEkOtrP1M
--HG--
extra : rebase_source : 2262af8fc3cb1aec8d9c8fc2762f3d61e188cb37
When an object is aggregated, doing a QI to anything other than IUnknown on the inner object AddRefs the outer object.
Thus, before releasing our reference to the inner IUnknown (and thus destroying it), we *must* release any references to interfaces queried from it.
Otherwise, any pointers to interfaces of the inner object would be invalidated.
MozReview-Commit-ID: KXsA8Sagx6G
--HG--
extra : rebase_source : f1dca4ee71f2ed49c8ba19c12862f2b4f9881fca
These conditions are rare and do indicate a problem which breaks accessibility.
However, we aren't getting any closer to diagnosing these as a result of these crashes, so they cause user pain without any gain to us.
MozReview-Commit-ID: D9U4et3Bg7d
--HG--
extra : rebase_source : a81263a0ef97a8ed87129d15ef30ded3005e740c
These conditions are rare and do indicate a problem which breaks accessibility.
However, we aren't getting any closer to diagnosing these as a result of these crashes, so they cause user pain without any gain to us.
MozReview-Commit-ID: D9U4et3Bg7d
--HG--
extra : rebase_source : a81263a0ef97a8ed87129d15ef30ded3005e740c
This fix is completely speculative, but I have strong reason to believe that
we are having lifetime issues, and that refcount stabilization might be coming
into play.
The situation is this:
Suppose we're aggregating an object, so we pass |this| as the outer IUnknown.
The inner object might perform AddRef() and Release() on |this| during its
initialization.
But if we're in the process of creating the outer object, that refcount might
not yet have been incremented by 1, so the inner object's invocation of the
outer object's Release() could trigger a deletion.
The way around this is to temporarily bump the refcount when aggregating another
object. The key, though, is to not do this via AddRef() and Release(), but by
direct maniuplation of the refcount variable, so that we don't trigger any of
the self-deletion stuff.
MozReview-Commit-ID: 3WA2AJvb6jY
--HG--
extra : rebase_source : ab05a52760541a4ab11f1245a5ddeae938998047
This patch adds two additional fields to each mscom log entry: The first is
the duration, in microseconds, of time spent in mscom overhead when executing
a call from the MTA on behalf of a remote client.
The second field is the duration, in microseconds, of time spent actually
executing the method within Gecko itself.
(In other words, the sum of the two fields will equal the total duration of
time spent executing the call.)
MozReview-Commit-ID: EhFieEPrhE5
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
MozReview-Commit-ID: 2pyAiw53rj7
Currently we wrap every outpointer interface with its own interceptor. Even two
identical interface outparams will get their own unique interceptors. Not only
does this violate COM object identity, but it is also inefficient; if an
interceptor already exists for a given interface, we should reuse it.
This patch adds a live set: when we create a new interceptor, we first check
the live set and reuse an existing interceptor if it is present. Otherwise we
create a new one and then insert it into the set.
The set uses thread-safe weak references to guard against races during
interceptor teardown.
--HG--
extra : rebase_source : fb3f11600fb368d169bd1164433e2d8780592146
MozReview-Commit-ID: AmS5oBNV7Po
When creating a new interceptor, we already have the correct target interface.
The interceptor ignores this and does a redundant inter-thread QI to resolve
an interface that we already have!
This patch adds a fast path to interceptor initialization that skips all of that
stuff and directly initializes itself using the given target interceptor.
--HG--
extra : rebase_source : dcfff7270efd5bda990e240bb06a9206656d5852
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
We install mozilla/mscom/Utils.h, but include it with an all-lowercased
path in some places. clang-cl warns about this, and even though this is
Windows-only code and will therefore work, it's better to make
everything consistent.
