This condition is rare and does indicate a problem which breaks accessibility.
However, we aren't getting any closer to diagnosing this as a result of this crash, so it causes user pain without any gain to us.
MozReview-Commit-ID: GacAQDbhB0h
--HG--
extra : rebase_source : 478ec67da378ff763c0e0d8a998de1956b51b85b
And likewise for AttrCharacteristics::attributeName.
MozReview-Commit-ID: DwGzWCCKcVP
--HG--
extra : rebase_source : ac595af0b0da2cee36b5aecf4474880fbe993f11
The singleton AccessibleHandlerControl maintains a global cache generation counter which is incremented whenever any node is changed.
The handler for each node tracks the cache generation at the time its cache was initialized.
To check whether the cache needs to be updated, the handler compares its generation against the global generation from AccessibleHandlerControl.
If they differ, it refreshes the cache.
Previously, the handler didn't update its cache generation after refreshing.
This meant that every single query after the first change would refresh the whole cache, even if there wasn't a second change.
This resulted in a huge number of wasted cache updates for clients such as JAWS which hold onto accessibles, rather than releasing them and fetching them again for each update.
MozReview-Commit-ID: 80d4n1cIjzQ
--HG--
extra : rebase_source : a0903ddb33eba5381a232a661deaa3754b92406f
BuildDynamicIA2Data can't return an HRESULT; failure is communicated by the fact that the unique id in the data is set to 0.
However, IGeckoBackChannel::Refresh returned S_OK even if BuildDynamicIA2Data failed.
We now check the unique id and return an appropriate error code if it's 0.
Among other things, this means that the handler will return an error when querying dead objects instead of returning stale cache data.
MozReview-Commit-ID: IorDRHCItD8
--HG--
extra : rebase_source : 1b3b8393309ccefac27d0228aa528cd6fa55ad35
A typo meant we were checking the address of mChildCount, not the value.
MozReview-Commit-ID: 7Hit3FBy9pr
--HG--
extra : amend_source : edb85b8e73184e47cd9ff42c0442f89d5f3c5152
Now that the handler implements IEnumVARIANT itself (and uses our own internal method to retrieve the children), caching this remote interface is pointless.
MozReview-Commit-ID: FyagiEcHMP2
--HG--
extra : rebase_source : 267568164fb46d98c8cde22dfbb4f36f2afceb8c
This implements IEnumVARIANT locally using the new method provided by HandlerProvider.
This avoids marshaling full objects for text leaf accessibles (instead using HandlerTextLeaf), which is much faster.
It also avoids a pointless cross-process call to IEnumVARIANT::Reset (and possibly IEnumVARIANT::Clone).
Finally, it caches children after the first query so that clients (such as UI Automation) which walk children one by one don't incur separate cross-process calls for every child.
MozReview-Commit-ID: KUIXQoXxInQ
--HG--
extra : rebase_source : a6c0a56c2bb65e227f7c45eb1b767e7df19efa49
For text leaf accessibles, the HandlerProvider::AllChildren property provides text and other necessary information in an AccChildData struct, rather than providing the full accessible object.
Therefore, we must provide a specific local implementation of IAccessible2 which answers queries based on the data provided in this struct.
MozReview-Commit-ID: 8BYMF59EoTe
--HG--
extra : rebase_source : 0cdc01158f7fd1a04b0751a0a1703f9aa03cbe4c
When considering a large document, a huge number of the children we return are text leaf nodes.
Marshaling full objects is expensive, but for text leaf nodes, the client is only interested in the text and a few other pieces of information.
Therefore, rather than returning the full object for text leaf accessibles, we just return the text and other necessary information.
For other non-text children, we return the full object as usual.
In addition, clients normally use the IEnumVARIANT interface to retrieve children in a single call.
However, it doesn't allow you to specify a starting index.
Therefore, you must first call the Reset method to reset the starting point to 0.
Practically, this means an extra cross-process call whenever the caller fetches children.
When dealing with a large document, this can be a significant number of wasted calls.
This new method retrieves all children always starting at the first using a single call.
MozReview-Commit-ID: A9lc7BBTWdb
--HG--
extra : rebase_source : d50507c182ab7760c17c5e7bb9956f46a3dc188c
If a handlerProvider call is pending on another thread, CoDisconnectObject won't release this HandlerProvider immediately.
However, the interceptor and its target might be destroyed.
MozReview-Commit-ID: 75SyPMIpit0
--HG--
extra : amend_source : a80f50f754c9be171e9262b13136e95005bc62af
To improve performance for cross-process COM, we disable COM garbage collection.
However, this means we never receive Release calls from clients, so defunct accessibles can never be deleted.
Since we know when an accessible is shutting down, we can work around this by forcing COM to disconnect this object from all of its remote clients, which will cause associated references to be released.
MozReview-Commit-ID: 5sIuxnaRJWj
--HG--
extra : rebase_source : e5c54e4f107b2db39d77277020aa939a6a283bd8
extra : histedit_source : 0a964ba20363cc1b8880d78e5d214dae0f758a01
To improve performance for cross-process COM, we disable COM garbage collection.
However, this means we never receive Release calls from clients, so defunct accessibles can never be deleted.
Since we know when an accessible is shutting down, we can work around this by forcing COM to disconnect this object from all of its remote clients, which will cause associated references to be released.
MozReview-Commit-ID: 5sIuxnaRJWj
--HG--
extra : rebase_source : 9059dbed02bf78b4be5b544c8b3bc14f0ca088c8
When an idl file is updated, files like HandlerData.h are generated as
part of the midl target (eg: midl_done). However, Make may have already
stat'd HandlerData.h and cached its timestamp. Although there is a
dependency from HandlerData.h on midl_done, there is no recipe. As such,
Make assumes that HandlerData.h hasn't actually changed, and uses the
cached value of the timestamp when determining if it should install the
file into dist/include. If the cached value is older, make may not
trigger the install rule, leaving the old header in place and breaking
the build.
MozReview-Commit-ID: 9rdtXIt8mXC
--HG--
extra : rebase_source : 8b22f1d6656d0dbc2c3b5dc53ea2b936fdd637bd
If a client calls IAccessible2::nRelations, it's likely that it will next call IAccessible2::relations to query each relation.
Furthermore, it's likely the client will call relationType and nTargets on each relation.
Therefore, fetch all of this info when nRelations is called.
The number of relations is immediately returned to the client.
The rest of the info is cached and returned to the client when the appropriate methods are called.
The info is only cached for one call; i.e. after the client calls relations once, the cache is dropped.
This makes memory management simpler and lowers the risk of cache invalidation problems.
MozReview-Commit-ID: IBoJbu42osG
--HG--
extra : rebase_source : d1af83f4c6c0e7762299e9e3da95a67217157200
The HandlerProvider::RelationsInfo method provides the type and number of targets for each relation in an IARelationData struct.
This local implementaition of IAccessibleRelation is constructed with an IARelationData struct and serves a single relation.
It uses the data from the struct to answer queries, except for actual targets.
For targets, it makes a remote call to IA2_2::relationTargetsOfType to answer the query.
We use relationTargetsOfType instead of IARelation::targets because marshaling so many IARelation pointers is a major bottleneck.
MozReview-Commit-ID: Dva00FhoSbx
--HG--
extra : rebase_source : 6dc2f46eb99e5c19ace89d0d9d21558b675ab68e
IAccessible2::relations allows you to fetch IAccessibleRelation objects for all relations.
However, you must first call IAccessible2::nRelations to get the number of relations.
In addition, getting the type and number of targets for each relation requires additional calls.
This new method allows all of this to be retrieved in a single cross-process call.
MozReview-Commit-ID: 3zEIjxEyMP5
--HG--
extra : rebase_source : 281217f4c0974040e35a197d0f1c555d9e4356fc
JAWS uses QueryService for these.
Using QI avoids a cross-process call, since we have these interfaces cached.
More importantly, if QS is used, the handler won't get used for that object, so our caching won't be used.
MozReview-Commit-ID: Ejc2Bjp7NSv
--HG--
extra : rebase_source : f0154a6691d4d6be97e9aa60b0613ff04f76b7ff
We just return failure for these, thus avoiding a pointless cross-process call.
I also updated the comment for an existing service, since I discovered its constant name.
MozReview-Commit-ID: E5hjhR6nYtv
--HG--
extra : rebase_source : 8f01da6b98a881809a106a03eb611aadc90a6d20
When querying text attributes, Gecko can return an end offset less than the requested offset in some rare cases, which isn't valid.
This is perhaps because the text mutated during the attribute fetching loop for some reason, making the requested offset invalid.
We now check the end offset and break out of the loop in this case.
This fixes a freeze after sending a message in OX Mail with NVDA.
MozReview-Commit-ID: 1lVSLAdOcS7
--HG--
extra : rebase_source : 048fbed8ddc591f62c17d559483bfe2f1542431c
Previously, it was querying for IID_IAccessibleHypertext, but this is actually an IAccessibleHypertext2 pointer.
This meant we were crashing when trying to call an IAccessibleHypertext2 method.
This was a regression introduced in bug 1419362.
MozReview-Commit-ID: 7akjIfNuIh3
--HG--
extra : rebase_source : 18e126e3b47bc5a8f486870a285668a7f85e95c9
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
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
Bug 873444 implemented support for IAccessibleHypertext2.
AccessibleHandler's AccessibleTextTearoff needs to be updated accordingly, thus eliminating an additional cross-process QueryInterface for IAHypertext2 when the client also wants IAText.
MozReview-Commit-ID: EGqYX7jY9Cp
--HG--
extra : rebase_source : cc79b605bf75538bebc10b104e5f6771bc52d2f4
AccessibleHandler's AccessibleTextTearoff currently makes separate queries for the IAccessibleText and IAccessibleHypertext interfaces.
However, IAccessibleHypertext inherits from IAccessibleText, and wherever one of these interfaces are present, Gecko always implements both.
Therefore, we should just query for and use IAccessibleHypertext for all of these methods, thus saving a cross-process call should a client want both interfaces.
MozReview-Commit-ID: Fb5P7IGDAZZ
--HG--
extra : rebase_source : 08c9484989eaf8b810ef6f9ababf354eee8fa7f8
IAccessibleHypertext::hyperlink returns an IAccessibleHyperlink, not an IAccessible2.
previously, the handler didn't know about this interface, so it wasn't used.
Thus, any accessibles retrieved in this way did not benefit from the cache.
This patch teaches the handler about IAccessibleHyperlink so the handler gets used in this case.
MozReview-Commit-ID: 17CxxGyCLrE
--HG--
extra : rebase_source : 7f933bfd880c9ee009eafe8cee4ece4ef83004cd
IAccessible2_2::get_attribute is not implemented yet in Gecko.
However, the handler still passes this through, thus resulting in a pointless cross-process call.
Instead, just return E_NOTIMPL in the handler for this method.
MozReview-Commit-ID: 5XHieUC4cuz
--HG--
extra : rebase_source : 814ceda6d9dd4ec26f05a4ff90bbd4af2a6eb84e
(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
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: 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.
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.
MozReview-Commit-ID: Kp8x5o66nrY
I want AccessibleHandler.dll to use different UUIDs based on release channel.
The way I was doing it before wasn't working correctly because I also wanted
local builds to have their own set of UUIDs vs our regular Nightly/Beta/Release
builds.
I also want the beta channel to have its own set of UUIDs that are distinct
from release.
I'm using MOZ_UPDATE_CHANNEL to distinguish between the channels when
NIGHTLY_BUILD and BETA_OR_RELEASE are insufficient.
--HG--
extra : rebase_source : 8cb28a22a3cac16fb743a8fe81db5e120c1fdf6d
We need to update mChildDocs on child document removal. This also cleans up some code related to setting a new child doc when one is already set -- we now assert that this cannot happen.
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
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
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.
sending the emulated window information is basically unrelated to sending the
parent COM proxy to the child process, and in the future it will be useful to
send these at different times.
the outer doc of a top level content document does not necessarily exist when
we recieve the PDocAccessibleConstructor message for it. So we shouldn't asser
there is an outer doc here.
There are cases where there is no good reason to shutdown the child document
actors before the parent. For example when TabParent::DestroyInternal() is
about to send the Destroy message we might as well just shut down the top level
document and let that tear down the rest.
Since it can be called in strange orderings wrt SetChildDoc() it seems
reasonable to believe we can get an ordering where the proxy has a document as
a child but is not marked as having document children.
After bug 1329814 a DocAccessibleParent can be shutdown by the parent process
before a content process has started shutting down the document that
DocAccessibleParent represents. That means the content processcan send an
event from a live document to a DocAccessibleParent that has already been
destroyed.
When TabChild recieves the Destroy message from its parent the doc accessibles
for that tab are shut down. However if the Shutdown message sent by
DocAccessible::Shutdown() isn't recieved before the child process handles the
runnable that sends __delete__ to the tab parent actor the parent can send a
message to the already shut down doc accessible child actor.
Since we will fire events in the correct order we can use the index of the
event target at the time the event is fired. This protects from weird cases
where the target is inserted, and then children before the target are removed.
Since we will fire events in the correct order we can use the index of the
event target at the time the event is fired. This protects from weird cases
where the target is inserted, and then children before the target are removed.
We will use the new type for the generated IPDL message handler
prototype to make sure correct error handling method is called.
MozReview-Commit-ID: AzVbApxFGZ0
