This implements some methods exposed on DOMWindowUtils and used by
reftests, for the WebRender codepath. The implementation is very similar
to the implementation in LayerTransactionParent.
MozReview-Commit-ID: HP8OxzIzS7P
In order to provide more details context of how client arrived at the unsafe
page, particularly in redirect case, we may have to add more information to
redirect chains including:
- referrer (if any)
- remote address.
- URL
We may want to use an idl interface instead of nsIPrincipal to store these
information
MozReview-Commit-ID: 3Uh4r06w60C
SetCursorPos is used by Flash's relative cursor motion behavior. It is blocked by the plugin sandbox. This patch allows it to run by proxying it on the main process.
--HG--
extra : histedit_source : 85515d398c0c107c2258185c0591a943b26e724a
This makes UpdateLayerTree synchronous enough to ensure that the layer
transaction from the child reaches the compositor. Given the comment in
http://searchfox.org/mozilla-central/rev/484d2b7f51b7aed035147bbb4a565061659d9278/dom/interfaces/base/nsIDOMWindowUtils.idl#106
this seems to be the original intent of this function anyways. Without this, we
can have a race between the child talking to the compositor and the child
talking to the parent talking to the compositor.
This also changes GetCompositorBridgeChild to work even when the widget doesn't
have a CompositorBridge
This makes UpdateLayerTree synchronous enough to ensure that the layer
transaction from the child reaches the compositor. Given the comment in
http://searchfox.org/mozilla-central/rev/484d2b7f51b7aed035147bbb4a565061659d9278/dom/interfaces/base/nsIDOMWindowUtils.idl#106
this seems to be the original intent of this function anyways. Without this, we
can have a race between the child talking to the compositor and the child
talking to the parent talking to the compositor.
This also changes GetCompositorBridgeChild to work even when the widget doesn't
have a CompositorBridge
This adds the call NS_SetCurrentThreadName() to the thread created using
base::Thread (e.g. the Compositor thread) so that the name gets annotated in the
crash report and displayed on socorro.
MozReview-Commit-ID: 9bNeHlhbicA
--HG--
extra : amend_source : a7c0c09e7fa057df4c0e212e1579961c3f9617b1
extra : histedit_source : 8919f69bc68861858105efed12cc0a37404b38b0
The lifetime of async IPDL returned promise may be longer than its actor.
That is, the handler (receiver) may have not resolve/reject the promise when the actor
is destroyed. In this case, we have to reject all the pending promises before
ActorDestroy() is called on the "sender" side.
Besides, the handler (receiver) can reject with reason "ActorDestroyed" to silently
cancel the promise without trying to reply to the remote actor which may
have died. The sender-side promise is responsible for rejecting the pending promises,
which will be done in MessageChannel::RejectPendingPromisesForActor().
MozReview-Commit-ID: 4XjmquZzDBO
--HG--
extra : rebase_source : 48539e35e4587e09be1d66497b1ea32d1a95ee9a
This function is arguably nicer than calling NS_ProcessNextEvent
manually, is slightly more efficient, and will enable better auditing
for NS_ProcessNextEvent when we do Quantum DOM scheduling changes.
The wrapper should have the same liftime as the underlying
MessageLoop. This patch use the MessageLoop's DestructionObserver to
manage the lifetime of the wrapper.
MozReview-Commit-ID: 44ps4TKl3yQ
The wrapper should have the same liftime as the underlying
MessageLoop. This patch use the MessageLoop's DestructionObserver to
manage the lifetime of the wrapper.
MozReview-Commit-ID: 44ps4TKl3yQ
The new telemetry tag is for probing the best IPC message pre-allocate size to avoid
realloc overhead. We only count those message size which is greater than 4096.
This tag integrates IPC_MESSAGE_SIZE and MESSAGE_MANAGER_MESSAGE_SIZE2 which
have both expired.
MozReview-Commit-ID: GjvuidGJ7pz
--HG--
extra : rebase_source : 1da13b3f2b5b042d0445abd6051993e2fb317f93
Takes functionality that was in the WebAuthentication class that now
needs to be handled by the parent process, and moves it to the
U2FTokenManager singleton class. U2FTokenManager is created on the
PBackground thread during the first WebAuthn transaction, and manages
hardware access and transaction management for the lifetime of the
browser session. Patch also adds parent classes for WebAuthn IPC
protocol.
MozReview-Commit-ID: EnhgUTPdlMZ
Takes functionality once in the WebAuthentication DOM class that needs
to be handled by the content process, and moves it to a
singleton (per-content-process) manager class. This allows the
WebAuthn API to centralize management of transactions and IPC
channels. Patch also creates the child (content-process) classes for
WebAuthn IPC channels.
MozReview-Commit-ID: 6ju2LK8lvNR
We proxy all accessibility information for the content through the main process
so its unnecessary and possibly confusing to expose accessibility information
from the content processes. Further ATK's use of dbus uses syscalls that we
would like to disallow within sandboxed content processes.
PLayerTransaction's constructor was previously synchronous so we could
return a TextureFactoryIdentifier. This is quite reliably available
already in the case of opening a tab, due to RenderFrameParent knowing
which compositor it is attached to, so we can make the constructor
asynchronous.
In the top-level widget case, we add a new synchronous message to find
the TextureFactoryIdentifier.
PLayerTransaction's constructor was previously synchronous so we could
return a TextureFactoryIdentifier. This is quite reliably available
already in the case of opening a tab, due to RenderFrameParent knowing
which compositor it is attached to, so we can make the constructor
asynchronous.
In the top-level widget case, we add a new synchronous message to find
the TextureFactoryIdentifier.
PLayerTransaction's constructor was previously synchronous so we could
return a TextureFactoryIdentifier. This is quite reliably available
already in the case of opening a tab, due to RenderFrameParent knowing
which compositor it is attached to, so we can make the constructor
asynchronous.
In the top-level widget case, we add a new synchronous message to find
the TextureFactoryIdentifier.
--HG--
extra : rebase_source : 4b29b859aa5745fabe3db0fe68742328fc0af175
Takes functionality that was in the WebAuthentication class that now
needs to be handled by the parent process, and moves it to the
U2FTokenManager singleton class. U2FTokenManager is created on the
PBackground thread during the first WebAuthn transaction, and manages
hardware access and transaction management for the lifetime of the
browser session. Patch also adds parent classes for WebAuthn IPC
protocol.
MozReview-Commit-ID: EnhgUTPdlMZ
--HG--
extra : rebase_source : e035b488ef4fc7a87e5038ed98db2abde05dc2db
Takes functionality once in the WebAuthentication DOM class that needs
to be handled by the content process, and moves it to a
singleton (per-content-process) manager class. This allows the
WebAuthn API to centralize management of transactions and IPC
channels. Patch also creates the child (content-process) classes for
WebAuthn IPC channels.
MozReview-Commit-ID: 6ju2LK8lvNR
--HG--
extra : rebase_source : 3d800902631ee88e3702c978e9d8ed9c6f88601f
This change moves most of the logic for the threadsafety check into
nsAutoOwningThread, rather than having part of the logic live in
nsAutoOwningThread and part of the logic live in nsDebug.h. Changing
this also forces us to clean up a couple of places that replicated the
logic that lived in nsDebug.h as well.
TimeStamp::ProcessCreations()'s aIsInconsistent outparam is ignored by the
majority of its caller. This patch makes it optional. Notably, this makes
ProcessCreation() easier to use in a constructor's initializer list.
In order to avoid a busy wait where we defer and then immediately un-defer a message,
we need to ensure that we only un-defer a message if it's actually ready to be processed.
This patch uses the same condition in MaybeUndeferIncall as we use in
DispatchInterruptMessage.
MozReview-Commit-ID: L2xZfSO0Yrk
IPCBlobInputStream must implement nsIIPCSerializableInputStream interface.
When this is done, the child sends the internal ID of the IPCBlobInputStream to
the parent.
IPCBlobInputStream is a new type of nsIInputStream that is used only in content
process when a Blob is sent from parent to child. This inputStream is for now,
just cloneable.
When the parent process sends a Blob to a content process, it has the Blob and
its inputStream. With its inputStream it creates a IPCBlobInputStreamParent
actor. This actor keeps the inputStream alive for following uses (not part of
this patch).
On the child side we will have, of course, a IPCBlobInputStreamChild actor.
This actor is able to create a IPCBlobInputStream when CreateStream() is
called. This means that 1 IPCBlobInputStreamChild can manage multiple
IPCBlobInputStreams each time one of them is cloned. When the last one of this
stream is released, the child actor sends a __delete__ request to the parent
side; the parent will be deleted, and the original inputStream, on the parent
side, will be released as well.
IPCBlobInputStream is a special inputStream because each method, except for
Available() fails. Basically, this inputStream cannot be used on the content
process for nothing else than knowing the size of the original stream.
In the following patches, I'll introduce an async way to use it.
Change mozilla::Smprintf and friends to return a UniquePtr, rather than
relying on manual memory management. (Though after this patch there are
still a handful of spots needing SmprintfFree.)
MozReview-Commit-ID: COa4nzIX5qa
--HG--
extra : rebase_source : ab4a11b4d2e758099bd0794d5c25d799a7e42680
Remove sync protocol AllocateTabId. Instead we generate tabId in
each process with nsContentUtils::GenerateTabId, and register
RemoteFrameInfo in parent process. If the tab id was generated from
a content process, it's sent parent through either PBrowserConstructor
or PContent::CreateChildProcess.
MozReview-Commit-ID: D3W2fK9eCNH
--HG--
extra : rebase_source : 1913f8f586537be1c82a70a19cc8c6351671d0df
This patch implements async returns for IPDL using MozPromises. There
are following changes:
* Initialize AbstractThreads for MessageLoops
* Record promises and their reject functions
* When async message returns, call their resolve functions
* When send error or channel close, call their reject functions
* Implement "unresolved-ipc-promises" count for about:memory
* Test cases
See bug attachment for generated code from test cases
MozReview-Commit-ID: 7xmg8gwDGaW
--HG--
rename : ipc/ipdl/test/ipdl/error/AsyncReturn.ipdl => ipc/ipdl/test/ipdl/ok/AsyncReturn.ipdl
extra : rebase_source : 9a5821d6c0e5f7152b8152a17a409b94e8258dc3
Everything depending on the widget being gonk can go away, as well as
everything depending on MOZ_AUDIO_CHANNEL_MANAGER, which was only
defined on gonk builds under b2g/ (which goes away in bug 1357326).
--HG--
extra : rebase_source : 9f0aeeb7eea8417fa4e06d662d566d67ecaf2a24
Before bug 1348069, MS manifest tool was used to embed manifest files.[1]
The Makefile used to use EXTRA_DEPS to invoke the manifest tool when a manifest files is changed. But it is no longer effective because the manifest file namepattern is no longer $@.exe.manifest.
Now manifest files will be embedded via .res files. So we have to rebuild .res files to update embedded manifests.
[1] https://dxr.mozilla.org/mozilla-central/rev/35c7be9c2db288d1d449e3cc586c4164d642c5fd/config/rules.mk#642-655
MozReview-Commit-ID: 5QiXVeImZdY
--HG--
extra : rebase_source : 9e321e30ecd389ef0aa21e438d321e79edf0a009
NPN_GetAuthenticationInfo is an NPAPI API we implemented for Java and since we only support Flash we no longer need it.
MozReview-Commit-ID: HxNn91QeaMB
--HG--
extra : rebase_source : 016320ce93bde525dbf1b74f50f8b60d141d31cd
One file was excluded for using plarena which it did not. The other was
excluded for "clashes with strdup," it does not use strdup.
MozReview-Commit-ID: 5X5H9S4j903
One file was excluded for using plarena which it did not. The other was
excluded for "clashes with strdup," it does not use strdup.
MozReview-Commit-ID: 5X5H9S4j903
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
