Syncing the container FeaturePolicy across BrowsingContext is actually
a bit more heavy-handed than necessary. We only ever need a container
FeaturePolicy when inheriting a FeaturePolicy in exactly the document
the container contains. Not every process that the tree the container
is a part of. So instead of storing a FeaturePolicy in a synced field,
we manually send it to the correct WindowGlobalChild (which
corresponds to a document) and retrieve it from there.
Differential Revision: https://phabricator.services.mozilla.com/D61479
Upon starting the RDD and GPU process; we check their decoding capabilities and send it to the parent process. It will then broadcast this information to all content children so that RemodeDecoderModule::Supports can return if a codec is supported or not.
Differential Revision: https://phabricator.services.mozilla.com/D100306
Upon starting the RDD and GPU process; we check their decoding capabilities and send it to the parent process. It will then broadcast this information to all content children so that RemodeDecoderModule::Supports can return if a codec is supported or not.
Differential Revision: https://phabricator.services.mozilla.com/D100306
We can launch the RDD process early now that it is a fully asynchronous process and doesn't block anything.
This will allow to retrieve the decoding capabilities of the RDD process right away.
Ideally, we should have been able to start the RDD process at the same time as the GPU process; however setting up the RDD sandbox is dependent of having mozilla::SandboxBroker::GeckoDependentInitialize() called first ; and it is called in the most awkward of places; so finding a place suitable for all platforms gets affected.
For now we will ensure it's been started around the time the first content process is started.
Differential Revision: https://phabricator.services.mozilla.com/D100304
This avoids us doing the full work of ExtractData every time a new content
process is created. That work is probably not super expensive, but without
this caching it does trip up
browser/base/content/test/performance/browser_preferences_usage.js due to
looking up a non-mirrored pref.
Differential Revision: https://phabricator.services.mozilla.com/D98990
This adds a new LookAndFeel implementation, RemoteLookAndFeel, which can
be used in content processes and is supplied with all of its values by the
parent process.
Co-authored-by: Cameron McCormack <cam@mcc.id.au>
Differential Revision: https://phabricator.services.mozilla.com/D97977
I think there could be still other issues with persist handling (or at least it could be simplified),
but this should be pretty much the minimal patch to fix the issue when
about:newtab url is changed to about:blank (without a redirect, but magical about: handling).
So we need to check persisted handling later than currently.
I'd prefer to land something like this first and then consider if there are better ways to handle
both about: url changes and proper redirects.
Depends on D93899
Differential Revision: https://phabricator.services.mozilla.com/D98871
The main-thread requirements for DXVA appear to have been needed when we initialized a crash guard. We now only run DXVA in the GPU and RDD processes, which don't support crash guards. This removes the main thread dispatch and the crashguard code, and enforces that we're in the GPU/RDD process to init DXVA.
This also removes the DLL blocklist code. This was disabled via pref when in the GPU process, which should be the majority of the time. In rare cases we would have been running DXVA in the RDD process (on older win7 when the GPU process isn't available). In these cases we can just do the same as the GPU process, allowing crashes and recovering from them (and disabling DXVA).
Differential Revision: https://phabricator.services.mozilla.com/D98036
Actually, our locale service doesn't use UTF-16 for locale name and it will
be ASCII. Although dictionary name of spell checker is locale/language name,
it still uses UTF-16. To use locale API, I should replace it with `ACString`.
Differential Revision: https://phabricator.services.mozilla.com/D99336
This was being called every time we created a ContentParent, which meant
that we'd get races with non-main-thread logging in the parent
process. This patch fixes it by only calling it once during process
startup.
The original goal was to avoid making logging noisier with process
information when e10s was not enabled, but given that e10s is the default
now, that is no longer relevant.
Differential Revision: https://phabricator.services.mozilla.com/D98935
The main-thread requirements for DXVA appear to have been needed when we initialized a crash guard. We now only run DXVA in the GPU and RDD processes, which don't support crash guards. This removes the main thread dispatch and the crashguard code, and enforces that we're in the GPU/RDD process to init DXVA.
This also removes the DLL blocklist code. This was disabled via pref when in the GPU process, which should be the majority of the time. In rare cases we would have been running DXVA in the RDD process (on older win7 when the GPU process isn't available). In these cases we can just do the same as the GPU process, allowing crashes and recovering from them (and disabling DXVA).
Differential Revision: https://phabricator.services.mozilla.com/D98036
The guess in comment 3 is basically right, here's the relevant bits that
happen in that trace in order:
[content] nsFrameLoaderOwner::ChangeRemotenessCommon:
frame becomes remote for the content process.
[parent] WindowGlobalParent::SendMakeFrameLocal (mIsDocumentLoad=true)
[content] ContentChild::SendCloneDocumentTreeInto
[parent] ContentParent::RecvCloneDocumentTreeInto
[content] WindowGlobalChild::RecvMakeFrameLocal
So basically the source frame we're cloning is mid-switch-to-local:
local already from the parent process POV, but still remote for the
child.
I think ignoring the clone in this case is fine (which will make the
print iframe just about:blank).
I've decided it to handle it in ChangeRemoteness but I could also handle
it in RecvCloneDocumentTreeInto with a check like
if (cp->GetRemoteType() == GetRemoteType())
or such I think. Let me know if you'd prefer that.
Differential Revision: https://phabricator.services.mozilla.com/D97144
mIPCOpen would incorrectly be `true` before the actual IPC channel had been
opened. By instead using the IPC-provided CanSend() method, we can avoid this.
Differential Revision: https://phabricator.services.mozilla.com/D95890
Previously, it was possible to accidentally shut down a content process while it
was still launching if the process switch which requested the switch was
cancelled.
Differential Revision: https://phabricator.services.mozilla.com/D95889
Previously we would call RemoveFromList, without calling MarkAsDead, when
ShutDownProcess was called called from ContentParent::LaunchSubprocessResolve.
This tripped some assertions in BrowsingContextGroup's host code.
Differential Revision: https://phabricator.services.mozilla.com/D95888
In bug 1595994 we attempted to streamline the ability to determine which decoder was available regardless of the process they would be running in. This was subsequently done via the PDMFactory.
As there are several JS API that can query which codec are supported, it requires a synchronous mechanism.
This allowed to make a determination during the PlatformDecoderModule::Supports call, depending on which process it was going to be called frome.
Having a synchronous IPC call to the RemoteDecoderManagerParent has too many caveats to be workable.
So what we do instead is first determine at launch if the required external framework are available and pass this information to each content process.
When checking if a decoder is available, we make a best guess at determining if the PDM would support such codec, without actually loading such framework when running in the content process.
Supports can no longer make a decision based on the process currently running and as such PDM::CreateAudio/VideoDecoder using an optional system framework now need to further check the validity of the CreateDecoderParam argument.
Differential Revision: https://phabricator.services.mozilla.com/D95245
Initialization of the ContentParent could modify some preferences, and we wouldn't be ready to send them to the ContentChild yet.
So we split a ALIVE into another INITIALIZED state to distinguist the two.
Differential Revision: https://phabricator.services.mozilla.com/D95244
Otherwise, if we return early, it will never get added, and we will crash when
trying to remove it when it's destroyed.
Differential Revision: https://phabricator.services.mozilla.com/D94487
This patch does:
- Use LSWriteOptimizer
- Remove SessionStorageService since it's unused.
- Move IPC from PContent to PBackground
(by SessionStorageManager{Child, Parent} and SessionStorageCache{Child, Parent}).
- Extract SessionStorageManagerBase and add PBackgroundSessionStorageManager.
- Expose a getter function to get a BackgroundParentManager for top context id
on the parent.
IPC
- Before this patch:
- Copy from parent while loading a document.
- Mark cache entry on the parent process as loaded by the child id.
- Update change on checkpoint.
- Unmark cache entry on the parent process as unloaded for the child id while
the parent actor is destorying.
- After this patch:
- Sync IPC load in the first SessionStorage operation.
- Update change on checkpoint
`BackgroundSessionStorageManager`'s lifecycle on the parent process.
- Create by `SessionStorageManagerParent` and register to the `sManagers`.
- Hold by `SessionStorageManagerParent` and `sManagers`.
- Remove from the `sManagers` while the corresponding `BrowsingContext` is
destructed (on the parent process).
Depends on D89341
Differential Revision: https://phabricator.services.mozilla.com/D89342
Because GeckoView content processes are hosted inside Android `Service`s, and because
there is a hard limit on those services, we cannot assume that it is safe to launch
a new content process while another one is still in the process of shutting down.
Calling `ContentParent::MarkAsDead` from `ContentParent::NotifyTabDestroying`
triggers such a scenario. By excluding this code from GeckoView builds, we
ensure that content processes remain live until GeckoView (or Android itself)
forcibly terminates them.
Differential Revision: https://phabricator.services.mozilla.com/D92650
Since the semantics of `ContentParent::MarkAsDead` are significantly different
from `GeckoProcessManager::MarkAsDead`, let's rename the latter to better
reflect what it actually does.
Differential Revision: https://phabricator.services.mozilla.com/D92649
In order to avoid over/under-counting, we need to treat window.print()
specially. The new UI was using aOpenWindowInfo.isForPrintPreview for
that, but that doesn't quite work for the old UI (because it will
trigger a regular print, not a preview).
But since isForPrintPreview was only really needed to distinguish
window.print(), just rename it and set it to true when the old UI is
triggered by window.print() as well.
Differential Revision: https://phabricator.services.mozilla.com/D92925
Various tests disable process preallocation in order to get "stable" process
counts for testing purposes. In order to keep this behaviour, we need to disable
and shut down the recycled E10S process whenever the preallocator is disabled.
This is accomplished by having the preallocator expose its enabled status to
ContentParent, and by having the preallocator trigger ContentParent shutdown
when it is disabled.
This also has the benefit of hooking the recycler back into memory pressure
notifications, meaning it will be shut down if not in use when a memory pressure
event occurs.
Differential Revision: https://phabricator.services.mozilla.com/D88628
This helper method abstracts over the common tasks performed in every normal
shutdown codepath. This will be useful for making process recycling respect
preallocation being disabled.
Differential Revision: https://phabricator.services.mozilla.com/D88627
It is uncommon to have long-lived "web" processes when Fission is enabled, so in
general we probably don't want to be performing content process recycling.
We also skip recycling web processes when E10s is disabled, as the process
preallocator would be disabled in that case, so recycling processes can lead to
mochitest-chrome test failures.
Differential Revision: https://phabricator.services.mozilla.com/D88626
Previously, we would use the PreallocatedProcessManager to handle recycled
"web" content processes, which would remove them from the pool and try to make
them act like "prealloc" content processes.
Unlike true preallocated content processes, we can end up having content loaded
in recycled "web" content processes, such as due to a new pop-up being created
at an inconvenient time during process teardown. The complexity around this
semi-prealloc state caused some assertion failures in other related code.
This new approach doesn't remove the recycled process from the process selection
pool. Instead, after process selection decides to spawn a new "web" process, a
pointer to the specific "recycled" content process is fetched and returned by
the process selection algorithm before asking the preallocator.
This new approach should have similar behaviour, but avoids some of the pitfalls
caused by removing the entry from the process selection pool after it has begun
hosting content.
Differential Revision: https://phabricator.services.mozilla.com/D88625
This works, though probably we want to do some follow-up tweaks, like
the adding of the onload blocker and so on, so that we can avoid the
UpdateDimensions hack.
We may also want a PrintObject in the nsPrintJob tree, perhaps...
Differential Revision: https://phabricator.services.mozilla.com/D90310
This has couple of different pieces and one may want to focus on each of those separately when
reviewing. The first two as small changes.
- Moving mDynamicallyCreated from nsDocShell to be a sync'ed field on BrowsingContext.
CanonicalBrowsingContext::CreateLoadingSessionHistoryEntryForLoad sets that on a newly created entry.
- Adding mActiveEntryIsLoadingFromSessionHistory. mLoadingEntry + mActiveEntryIsLoadingFromSessionHistory has roughly
the same lifetime as mLSHE. mLoadingActiveEntry is needed so that child docshell can know whether its parent is loading from session history.
- The main part is in MaybeHandleSubframeHistory which checks if the parent docshell is loading from session history,
and if so, asks for a LoadingSessionHistoryInfo. In the case of docshell living in a child process that operation is asynchronous,
so when the data is back from the parent process, LoadURI is called again with the possibly updated data.
One could possibly split the code to smaller methods and then deal with aContinueHandlingSubframeHistory only in LoadURI,
but MaybeHandleSubframeHistory does have some early returns which would make that approach possibly hard to follow.
Differential Revision: https://phabricator.services.mozilla.com/D89685
ChildSHistory.legacySHistory isn't valid for content processes when
session history in the parent is enabled. We try to fix this by either
delegating to the parent by IPC or move the implementation partially
or as a whole to the parent.
Differential Revision: https://phabricator.services.mozilla.com/D89353
This backs out all work from bug 1627075 as well as all of its
descendents. There were a few conflicts when backing this out but
overall it was pretty clean, so I would say it's a fairly mild
level of risk. Historically Nathan Froyd has reviewed these patches,
but he is no longer at Mozilla, and no one else is particularly
familiar with the code, so I am passing this off to RyanVM who has
at least been familiar with the history of the bug.
Differential Revision: https://phabricator.services.mozilla.com/D90096
Various tests disable process preallocation in order to get "stable" process
counts for testing purposes. In order to keep this behaviour, we need to disable
and shut down the recycled E10S process whenever the preallocator is disabled.
This is accomplished by having the preallocator expose its enabled status to
ContentParent, and by having the preallocator trigger ContentParent shutdown
when it is disabled.
This also has the benefit of hooking the recycler back into memory pressure
notifications, meaning it will be shut down if not in use when a memory pressure
event occurs.
Differential Revision: https://phabricator.services.mozilla.com/D88628
This helper method abstracts over the common tasks performed in every normal
shutdown codepath. This will be useful for making process recycling respect
preallocation being disabled.
Differential Revision: https://phabricator.services.mozilla.com/D88627
It is uncommon to have long-lived "web" processes when Fission is enabled, so in
general we probably don't want to be performing content process recycling.
We also skip recycling web processes when E10s is disabled, as the process
preallocator would be disabled in that case, so recycling processes can lead to
mochitest-chrome test failures.
Differential Revision: https://phabricator.services.mozilla.com/D88626
Previously, we would use the PreallocatedProcessManager to handle recycled
"web" content processes, which would remove them from the pool and try to make
them act like "prealloc" content processes.
Unlike true preallocated content processes, we can end up having content loaded
in recycled "web" content processes, such as due to a new pop-up being created
at an inconvenient time during process teardown. The complexity around this
semi-prealloc state caused some assertion failures in other related code.
This new approach doesn't remove the recycled process from the process selection
pool. Instead, after process selection decides to spawn a new "web" process, a
pointer to the specific "recycled" content process is fetched and returned by
the process selection algorithm before asking the preallocator.
This new approach should have similar behaviour, but avoids some of the pitfalls
caused by removing the entry from the process selection pool after it has begun
hosting content.
Differential Revision: https://phabricator.services.mozilla.com/D88625
This patch enables sandboxed srcdoc loads to take place via DocumentChannel,
and adds mechanisms for enabling unsandboxed ones.
Both unsandboxed srcdoc, and in subsequent patches, about:blank, loads require
that the triggering principal and the principal to inherit point to the same
instance if the load takes place in the same process as where we are inheriting
those principals from. We save those principals on a target browsing context before
we load the URI, and later, when we are deserializing LoadInfoArgs into
LoadInfo in the content process, we retrieve the saved principals if the
current load identifier of the target BC matches the load identifier saved
along with the principals.
We also need to make sure that during a process switch for about:srcdoc load,
we don't use the original URI for about:srcdoc to determine the remote type and
instead we use channel's result principal.
Differential Revision: https://phabricator.services.mozilla.com/D85079
This centralizes our print and preview setup in nsGlobalWindowOuter so
that we never re-clone a clone, and so that we reuse the window.open()
codepath to create the browsing context to clone into.
For window.print, for both old print dialog / silent printing and new
print preview UI, we now create a hidden browser (as in with visibility:
collapse, which takes no space but still gets a layout box).
* In the modern UI case, this browser is swapped with the actual print
preview clone, and the UI takes care of removing the browser.
* In the print dialog / silent printing case, the printing code calls
window.close() from nsDocumentViewer::OnDonePrinting().
* We don't need to care about the old print preview UI for this case
because it can't be open from window.print().
We need to fall back to an actual window when there's no
nsIBrowserDOMWindow around for WPT print tests and the like, which don't
have one. That seems fine, we could special-case this code path more if
needed but it doesn't seem worth it.
Differential Revision: https://phabricator.services.mozilla.com/D87063
SessionHistoryEntry::MaybeSynchronizeSharedStateToInfo call is a tad controversial, but
something like that is needed for the cases when the actual value lives in the SHEntrySharedParentState.
Differential Revision: https://phabricator.services.mozilla.com/D86640
SessionHistoryEntry::MaybeSynchronizeSharedStateToInfo call is a tad controversial, but
something like that is needed for the cases when the actual value lives in the SHEntrySharedParentState.
Differential Revision: https://phabricator.services.mozilla.com/D86640
Out-of-process WebGL needs GfxInfo to exist in the composition
process (which is the GPU process if it exists and the parent process
otherwise). This patch enables the Linux version of that component in
the GPU process; the IPC currently used to give content processes copies
of the parent's GPU info is extended to also send it to the GPU process.
Differential Revision: https://phabricator.services.mozilla.com/D85443
Previously similar logic existed in BlobURLProtocolHandler, which has now been removed, since such checks are now for parent process only and should be abstracted from BlobURLProtocolHandler.
Depends on D75293
Differential Revision: https://phabricator.services.mozilla.com/D81126
The content process should use this method to send blob url and triggering principal to the parent process and expect blobImpl in return, if the blob is found and the triggering principal subsumes the blob's principal.
Differential Revision: https://phabricator.services.mozilla.com/D75291
This patch enables sandboxed srcdoc loads to take place via DocumentChannel,
and adds mechanisms for enabling unsandboxed ones.
Both unsandboxed srcdoc, and in subsequent patches, about:blank, loads require
that the triggering principal and the principal to inherit point to the same
instance if the load takes place in the same process as where we are inheriting
those principals from. We save those principals on a target browsing context before
we load the URI, and later, when we are deserializing LoadInfoArgs into
LoadInfo in the content process, we retrieve the saved principals if the
current load identifier of the target BC matches the load identifier saved
along with the principals.
We also need to make sure that during a process switch for about:srcdoc load,
we don't use the original URI for about:srcdoc to determine the remote type and
instead we use channel's result principal.
Differential Revision: https://phabricator.services.mozilla.com/D85079
Before this change, nsIDOMProcess{Parent,Child} could not directly be used in
do_QueryActor, as they don't directly inherit from JSActorManager.
The std::enable_if_t trickery is required in order to avoid overload issues when
passing types like ContentChild which inherit from both JSActorManager and
nsIDOMProcess{Parent,Child}.
Differential Revision: https://phabricator.services.mozilla.com/D84068
Previously we would end up throwing an uncatchable exception if actor
construction failed with an exception, due to calling
NoteJSContextException(cx), and then exiting a AutoEntryScript, which will clear
the exception on the JSContext and report it.
Differential Revision: https://phabricator.services.mozilla.com/D84066
This will let people get information about the process more easily.
remoteType can't be infallible because it is a ACString.
Differential Revision: https://phabricator.services.mozilla.com/D85776
Out-of-process WebGL needs GfxInfo to exist in the composition
process (which is the GPU process if it exists and the parent process
otherwise). This patch enables the Linux version of that component in
the GPU process; the IPC currently used to give content processes copies
of the parent's GPU info is extended to also send it to the GPU process.
Differential Revision: https://phabricator.services.mozilla.com/D85443
Csoregi Natalia
Henri Sivonen
Christoph Kerschbaumer
Andreas Farre
Mihai Alexandru Michis
Nika Layzell
Jean-Yves Avenard
Jonathan Kew
Cosmin Sabou
Razvan Maries
Masatoshi Kimura
Cameron McCormack
Jed Davis
Peter Van der Beken
Olli Pettay
Matt Woodrow
Makoto Kato
Andrew McCreight
Bogdan Tara
R. Martinho Fernandes
Butkovits Atila
Simon Giesecke
Emilio Cobos Álvarez
Johann Hofmann
Gerald Squelart
Kartikaya Gupta
Valentin Gosu
Narcis Beleuzu
Randell Jesup
Kris Maglione
Tom Tung
Aaron Klotz
julianwels
Brindusan Cristian
Nico Grunbaum
Dorel Luca
Andrea Marchesini
Barret Rennie
Doug Thayer
Mark Banner
Noemi Erli
Anny Gakhokidze
Agi Sferro
ssengupta