This ChromeUtils API now returns a promise that gets resolved once all the data
has been collected via IPDL and the main process. The existing notification
design and its related XPCOM classes are removed.
MozReview-Commit-ID: CYKukBOC8yh
--HG--
extra : rebase_source : 1e27524726ace0bfed5297d48af8be268c5b4945
Currently, in order to retrieve supported clipboard formats
DataTransfer::CacheExternalClipboardFormats repeatedly makes the same calls to
clipboard->HasDataMatchingFlavors.
In the case when aPlainTextOnly == true only 1 call is made -
clipboard->HasDataMatchingFlavors(kUnicodeMime, ...), and when
aPlainTextOnly == false we have 1 call made for every member of the list
{ kCustomTypesMime, kFileMime, kHTMLMime, kRTFMime, kURLMime, kURLDataMime,
kUnicodeMime, kPNGImageMime } - a total of 8 calls.
We can see that in nsClipboardProxy::HasDataMatchingFlavors, there is a call to
ContentChild::GetSingleton()->SendClipboardHasType.
So when aPlainTextOnly == true, we will have 1 sync message, and when
aPlainTextOnly == false, we will have 8 sync messages.
With the proposed solution, in DataTransfer::CacheExternalClipboardFormats
we will only have 1 sync message regardless of the case because
GetExternalClipboardFormats() will retrieve all supported clipboard
formats at once.
MozReview-Commit-ID: CAmBfqB459v
--HG--
extra : rebase_source : 27f1b420f2613e6a747ed63762f1583ab71ba3e0
Summary:
This patch adds the infrastructure to move Activity Stream (about:newtab, about:home,
and about:welcome) into its own special content process - the privileged content
process. This feature of running Activity Stream in the privileged content process
is disabled by default. (See "browser.tabs.remote.separatePrivilegedContentProcess"
preference.) We can deal with other about: pages in a follow-up.
Reviewers: mconley
Tags: #secure-revision
Bug #: 1469072
Differential Revision: https://phabricator.services.mozilla.com/D1731
MozReview-Commit-ID: 5gIrP4LxcIt
--HG--
extra : rebase_source : d43c411ae60aad3d5a3a496e6729de0b547b4acd
This is fairly straightforward, other than the fact that the
nomenclature gets a bit awkward with the aForce parameter on
the ForcePaint methods. I'm not sure which direction to go with
this - "aForce" seems a fairly intuitive name for what we want,
and I'm kind of inclined to say the existing ForcePaint mechanic
should be renamed to something like PaintWithInterrupt, or
PaintWithPriority.
MozReview-Commit-ID: Bj9DROug1pC
--HG--
extra : rebase_source : a3d91fec940d83325d36bafb13fe892e9c9530e8
This patch was reviewed in parts, however the intermediate states would not build:
Bug 1443954 - Part 3A: Strip pointers from the argument to WriteParam and WriteIPDLParam before selecting the ParamTraits impl, r=froydnj
Bug 1443954 - Part 3B: Move nsIAlertNotification serialization to the refcounted system, r=bz
Bug 1443954 - Part 3C: Move geolocation serialization to the refcounted system, r=bz
Bug 1443954 - Part 3D: Move nsIInputStream serialization to the refcounted system, r=baku
Bug 1443954 - Part 3E: Move BlobImpl serialization to the refcounted system, r=baku
Bug 1443954 - Part 3F: Correctly implement ParamTraits for actors after the ParamTraits changes, r=froydnj
This new module simplifies how we interact with PerformanceInfo counters:
- CollectPerformanceInfo: returns all PerformanceInfo instances
- NotifyPerformanceInfo: converts PerformanceInfo in XPCOM and notify them
MozReview-Commit-ID: JedKEtsbQTF
--HG--
extra : rebase_source : c87ad34f116a789f909c480963fb99cae3fafa6d
The new struct is in LayersTypes.h, all the rest of the changes are just
replacing existing uint64_t instances with the new LayersId struct.
Note that there is one functional change, in
CompositorBridgeParent::DeallocPWebRenderBridgeParent, where we now
correctly convert the PipelineId to a LayersId before using it to index
into sIndirectLayerTrees, whereas before we were incorrectly just using
the mHandle part of the PipelineId.
MozReview-Commit-ID: GFHZSZiwMrP
--HG--
extra : rebase_source : d2b274f63aaee2ee9bba030297e0a37a19af0d6c
Adds the IPDL layer to asynchronously retrieve in the parent process the performance counters.
MozReview-Commit-ID: RbKstNx8pi
--HG--
extra : rebase_source : d7c00f2ef16623dbbd88ede0f6636ca56501e151
Adds the IPDL layer to asynchronously retrieve in the parent process the performance counters.
MozReview-Commit-ID: RbKstNx8pi
--HG--
extra : rebase_source : f81058b9bdd67c2f77bb5cd45d3838bc12f406ea
Adds the IPDL layer to asynchronously retrieve in the parent process the performance counters.
MozReview-Commit-ID: RbKstNx8pi
--HG--
extra : rebase_source : 673bbf79f5e20493eee5e129f6954c574c9c41b6
Right now the only parameter will be sent via the IPC message is form URI.
IPC is triggered when a password field is focusd (See P2.)
MozReview-Commit-ID: J8lVwRhTFIr
--HG--
extra : rebase_source : b948cf1a719c9a06100c54f3eda526ea6f7cf848
The nsIU2FToken and its implementors are no longer needed; the soft token was
re-implemented into dom/webauthn/U2FSoftTokenManager.cpp during the WebAuthn
implementation. When the dom/u2f/ code changed to the implementation from
WebAuthn, the old synchronous version became dead code.
This patch removes the dead code.
MozReview-Commit-ID: 2yDD0tccgZr
--HG--
extra : rebase_source : 0f14d8de8f62599a41c13aa4d8fc9cdbc1fd79c7
The nsIU2FToken and its implementors are no longer needed; the soft token was
re-implemented into dom/webauthn/U2FSoftTokenManager.cpp during the WebAuthn
implementation. When the dom/u2f/ code changed to the implementation from
WebAuthn, the old synchronous version became dead code.
This patch removes the dead code.
MozReview-Commit-ID: 2yDD0tccgZr
--HG--
extra : transplant_source : %B3%96Te%E7%02%08%98%1A%B2%FA%1C%40%C4J%BC%B2%85j%81
NO_REMOTE_TYPE seems to have been an artifact of introducing remote types and
not wanting to change things. This eliminates the type, changing
GetNewOrUsedBrowserProcess() to no longer use a default argument so that
callers must think about the remote type they want. Additionally, the existing
call-site used by xpcshell in nsEmbedFunctions.cpp is updated to use the
DEFAULT_REMOTE_TYPE of "web", as-is the unused nsAppRunner.cpp case. (That is,
no one appears to call nsXULAppInfo::EnsureContentProcess directly or via its
XPCOM interface, and so it probably should be removed. However, since I
potentially want this patch uplifted to beta 56 and legacy extensions exist
there, we're not addressing that in this patch.)
--HG--
extra : rebase_source : bb87ec781d041bcea49268585bb5b45522b19bc2
We want to avoid to have several cached content processes, one for each
preloaded browser (one per window) and one for the preallocated process.
For that we force the preloaded browser to choose an existing process and
during the first navigation in that tab, that leaves about:newtab, we re-run
the process selecting algorithm
BHRTelemetryService only runs in the parent process (and we can only submit
pings from there), so we need to send the data which we collect in the GPU and
Content processes over IPC to the parent process.
MozReview-Commit-ID: 8B5uZKbjNbU
We want to avoid to have several cached content processes, one for each
preloaded browser (one per window) and one for the preallocated process.
For that we force the preloaded browser to choose an existing process and
during the first navigation in that tab, that leaves about:newtab, we re-run
the process selecting algorithm
This gives JS callers access to the remote type of remote message managers.
There's currently no way for extensions to access this unless they have a
<browser> element to check the remoteType attribute of.
MozReview-Commit-ID: A8Y3ZSG3rt8
--HG--
extra : rebase_source : e024922522da9a30265f05e9a8dbf7529dfe1d81
JS code is notified when a new ContentParent is created via normal
"ipc:content-created" notifications, but can't do anything with it, since
nsIContentParent is not scriptable. This allows JS callers to retrieve the
parent process message manager, which is the normal way they interact with
content children.
MozReview-Commit-ID: 7lcZ4XkJ6uR
--HG--
extra : rebase_source : f891c0e29863fc42fc2351a791ca3f1f7e2824b9
We want to avoid to have several cached content processes, one for each
preloaded browser (one per window) and one for the preallocated process.
For that we force the preloaded browser to choose an existing process and
during the first navigation in that tab, that leaves about:newtab, we re-run
the process selecting algorithm
We want to avoid to have several cached content processes, one for each
preloaded browser (one per window) and one for the preallocated process.
For that we force the preloaded browser to choose an existing process and
during the first navigation in that tab, that leaves about:newtab, we re-run
the process selecting algorithm
BHRTelemetryService only runs in the parent process (and we can only submit
pings from there), so we need to send the data which we collect in the GPU and
Content processes over IPC to the parent process.
MozReview-Commit-ID: 8B5uZKbjNbU
We want to avoid to have several cached content processes, one for each
preloaded browser (one per window) and one for the preallocated process.
For that we force the preloaded browser to choose an existing process and
during the first navigation in that tab, that leaves about:newtab, we re-run
the process selecting algorithm
Without this patch, all remote process types share a process name of
"Web Content". With this patch, specific names are added for "file",
"extension", and "webLargeAllocationTypes", with the default of "web"
left as the default "Web Content".
This patch also eliminates undocumented b2g-era legacy logic that had a
notion of whether it's acceptable to override the process name. In the
b2g era, I believe processes were named based on the "app" that was
running. It would have made sense to have the process initially named
the preallocated process, then to change the process to its app name
when specialized, trying to make it hard/impossible for the process to
rename itself so it couldn't masquerade as another app if it became
compromised.
--HG--
extra : source : c76be2df2c2855ddf2fafc323ddb2898dd65eba4
We removed all uses of GetBlocklistState in bug 1350640. This patch
removes the message and supporting functions from the PContent IPDL.
MozReview-Commit-ID: 4JtGAWZ0nPu
--HG--
extra : rebase_source : 4eb3c21e3768e9d8284d4eec129e099be5ef17d0
This changes CrashReporterHost::GenerateMinidumpAndPair() and up the caller chain to use callbacks so we
may call it synchronously or asynchronously.
MozReview-Commit-ID: 4PQH6cVdOk0
It is possible in extreme cases that the Telemetry IPC Accumulator might be
starved long enough that it cannot drain its stored accumulations for a while.
Once we hit 5x the high water mark, start discarding data.
Count each piece and type of discarded data and report it via a custom IPC
message.
MozReview-Commit-ID: JayRpa5QPec
--HG--
extra : rebase_source : eded449c932ced64bdb64e9da1a989407f4f2daf
To prevent addons or other code to rapidly create and destroy content processes
under various conditions, we let the preallocated process manager to reuse short
lived content processes.
Every JS plugin is assigned a unique ID. When an instance of a JS plugin is created the
frame loader that we use to load the plugin's handler URI will create a special
TabContext. This TabContext causes the ContentParent to use the process for this specific
JS plugin (creating one if it hasn't already) when it creates the PBrowser actors.
This causes the iframes for all the instances of a specific JS plugin to be grouped in the
same process.
--HG--
extra : rebase_source : c39560bdf66cda1a005c7b823b3a46e4734878a4
extra : source : 9cba1db527c7eed4371c9f4caf96fd942608cab6
This event is no longer necessary, since checking nsITabParent.hasPresented is enough to know
if we need to blank out the tab or not.
MozReview-Commit-ID: 445XMqhorxC
--HG--
extra : rebase_source : 1a05de827502c409d979a621471978b08ce39fb2
Changes:
- remove code addressed by reviewer
- remove PContent.ipdl, PBrowser.ipdl, and ProcessPriorityManager code
that relates only to removed AudioChannelService methods
- correct test case listening to event from removed code
- remove useless test case files
MozReview-Commit-ID: I96nR8zTXJt
--HG--
extra : rebase_source : 127876c672744811c025ca55839ff2e8a06b1fce
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 replaces the usage of sNextTabParent pointer to store the next
PBrowser parent actor to be used by the next frame loader with the
following information:
* In the case where the content JS has requested a new tab, the ID of the
next TabParent will be stored on the <xul:browser> element.
* In the case where the content JS has requested a new window, the ID of
the next TabParent will be stored on the created nsXULWindow.
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.
The goal of this patch is to remove the call to the sync IPC
GetCompositorOptions message from TabChild::InitRenderingState. In order
to this, we have InitRenderingState take the CompositorOptions as an
argument instead, and propagate that backwards through the call sites.
Eventually we can propagate it back to a set of already-sync IPC
messages in PCompositorBridge that are used during layers id
registration (NotifyChildCreated, NotifyChildRecreated, etc.). Therefore
this patch effectively piggybacks the CompositorOptions sync IPC onto
these pre-existing sync IPC messages.
The one exception is when we propagate it back to the AdoptChild call.
If this message were sync we could just use it like the others and have
it return a CompositorOptions. However, it is async, so instead we add
another call to GetCompositorOptions here temporarily. This will be
removed in the next patch.
MozReview-Commit-ID: AtdYOuXmHu4
--HG--
extra : rebase_source : 5b80831cf84d3a4b57b2214a12ccf8a896cfa3a7
We add a new "on-off" protocol PURLClassifierLocal which calls
nsIURIClassifier.asyncClassifyLocalWithTables on construction and
calls back on destruction. Pretty much the same design as PURLClassifier.
In order to avoid code duplication, the actor implementation is templatized
and |MaybeInfo| in PURLClassifier.ipdl is moved around.
Test case is included and the custom event target is not in place for labelling.
The custom event target will be done in Bug 1353701.
MozReview-Commit-ID: IdHYgdnBV7S
--HG--
extra : rebase_source : ab1c896305b9f76cab13a92c9bd88c2d356aacb7
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
This is the most important part of the patch series. It removes the
PScreenManager protocol and use ScreenManager directly in the content
processes.
Initial and subsequent updates are sent via PContent::RefreshScreens.
struct ScreenDetails are kept to serialize Screen over IPC.
nsIScreenManager::ScreenForNativeWidget is removed because
nsIWidget::GetWidgetScreen can replace it. nsIScreen::GetId is removed
because it's not useful for the more general Screen class.
MozReview-Commit-ID: 5dJO3isgBuQ
--HG--
extra : rebase_source : 06aa4e4fd56e2b2af1e7483aee7c0cc7f35bdb97
It's not used anywhere. Remove it will make removing PScreenManager
easier.
MozReview-Commit-ID: 5dn8kDhTZVl
--HG--
extra : rebase_source : 96b8ddb18deee94ca256bfa118b60ceacfd2d677
Tarek Ziadé
Kris Maglione
Anny Gakhokidze
imjching
Alex Gaynor
Cosmin Sabou
Peter Van der Beken
Doug Thayer
Nika Layzell
Kartikaya Gupta
Noemi Erli
Hector Zhao
Andrea Marchesini
Mike de Boer
Csoregi Natalia
Kate McKinley
Matthew Gregan
DimiL
Ben Kelly
Thomas Nguyen
Johann Hofmann
Gabriele Svelto
shindli
Jonathan Kew
Eugen Sawin
FSeita
J.C. Jones
Phil Ringnalda
Andrew Sutherland
Michael Layzell
Sebastian Hengst
Bevis Tseng
Stone Shih
Gabor Krizsanits
Carsten "Tomcat" Book
Stephen A Pohl
Wes Kocher
Jan Varga
Amy Chung
Nicholas Nethercote
Kyle Machulis
Christoph Kerschbaumer
Cervantes Yu
Chris H-C
domfarolino@gmail.com
Ryan VanderMeulen
Markus Stange
sotaro
Ehsan Akhgari
Mike Conley
btian
David Anderson
Ehsan Akhgari
Samael Wang
Bill McCloskey
Henry Chang
Aaron Klotz
Kan-Ru Chen