EnsureInit takes a long time to run on Linux, in addition to it's
timing, it also runs within a critical path of MSG_ConstructBrowser.
Scheduling it as an idle runnable gives it a chance to run
before MSG_ConstructBrowser.
Differential Revision: https://phabricator.services.mozilla.com/D83230
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
This should make the optimization landed earlier in this bug apply for
some of the NotifyThemeChanged() calls in nsWindow.cpp which are causing
all the extra invalidations.
If we know that system colors/fonts didn't change, we can avoid doing a
bunch of reflow work and the patch from earlier in the bug can avoid
re-rasterizing images too.
Differential Revision: https://phabricator.services.mozilla.com/D94425
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
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
This requires adding the flag as a synced field on the BrowsingContext, and
checking it in a few more places. Attempts to open a new window in this racy
manner will now raise an exception.
This should avoid the issue from bug 1658854 by blocking the buggy attempts to
load before the nested event loop has been exited.
Differential Revision: https://phabricator.services.mozilla.com/D87927
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
I did notice this issue while investigating a test failure on
browser/components/contextualidentity/test/browser/browser_serviceworkers.js
The issue seems to be triggered when we are using a preallocated child process
for a call to RemoteWorkerManager::LaunchNewContentProcess, when that happens
we do expect that the new process is going to call RemoteWorkerManager::RegisterActor
once its RemoteWorkerService is being initialized in the new child process,
but when we are reusing a preallocated child process the RemoteWorkerService
was already initialized and RegisterActor was already called while the
remoteType for the child process was still "prealloc".
This patch fix the failure by deferring initializing RemoteWorkerService in
child processes to when we do receive a non "prealloc" remoteType in
ContentChild::RecvRemoteType.
Differential Revision: https://phabricator.services.mozilla.com/D86590
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
I did notice this issue while investigating a test failure on
browser/components/contextualidentity/test/browser/browser_serviceworkers.js
The issue seems to be triggered when we are using a preallocated child process
for a call to RemoteWorkerManager::LaunchNewContentProcess, when that happens
we do expect that the new process is going to call RemoteWorkerManager::RegisterActor
once its RemoteWorkerService is being initialized in the new child process,
but when we are reusing a preallocated child process the RemoteWorkerService
was already initialized and RegisterActor was already called while the
remoteType for the child process was still "prealloc".
This patch fix the failure by deferring initializing RemoteWorkerService in
child processes to when we do receive a non "prealloc" remoteType in
ContentChild::RecvRemoteType.
Differential Revision: https://phabricator.services.mozilla.com/D86590
Right now they start with a FullyHidden() effect info, but with a
"visible" widget, and thus active docshell and so on.
That's no good :)
Differential Revision: https://phabricator.services.mozilla.com/D86364
Right now they start with a FullyHidden() effect info, but with a
"visible" widget, and thus active docshell and so on.
That's no good :)
Differential Revision: https://phabricator.services.mozilla.com/D86364
Right now they start with a FullyHidden() effect info, but with a
"visible" widget, and thus active docshell and so on.
That's no good :)
Differential Revision: https://phabricator.services.mozilla.com/D86364
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
This should make it easier to get an XPCOM interface from a JSProcessActorChild
in the current process, when combined with the do_QueryActor overloads from p2.
Differential Revision: https://phabricator.services.mozilla.com/D84069
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
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
This patch uses IPDL's return feature to ensure that the memory
reporter manager won't wait for a report from a child process
that has already exited.
This fixes a memory reporter hang that can happen if a child process
exits during a memory report, when the parent half of the actor is
being held alive. (If the parent half of the actor is not being held
alive, then mMemoryReportRequest will be naturally cleared when it
goes away.)
This was happening frequently on Windows Fission AWSY because that test
does a minimize memory right before it attempts to get a memory report,
and the preallocated content process exits when it sees a message to
minimize memory.
Differential Revision: https://phabricator.services.mozilla.com/D85499
The next patch converts the memory reporting architecture to use the "returns"
feature of IPDL, and mozilla::ipc::RejectCallback does not have a return
type, so this patch removes the return value.
FinishReportingCallback::Callback() needs to remain an XPCOM method
that returns NS_OK because it is called from JS during testing.
Differential Revision: https://phabricator.services.mozilla.com/D85498
Content processes will now receive cached values for GetFontImpl() from the
parent process during initialization and whenever the theme changes.
This eliminates the use of several Win32k calls in content.
Differential Revision: https://phabricator.services.mozilla.com/D83406
so that this happens even when the content sandbox is not enabled.
CubebUtils::InitLibrary() is called during ContentProcess::Init(), before the
event loop is run in XRE_InitChildProcess().
Differential Revision: https://phabricator.services.mozilla.com/D84941
Prior to this patch, we were sending a boolean from InitContentChild (which
creates our StartupCache IPC actors) indicating whether we wanted to collect
new entries from a given process or not. This was so that we wouldn't accept
PutBuffer requests in these processes, since collecting them in one process
would be enough, and we don't want to waste memory. However, we actually
want the cache to be available before we can even get that IPC constructor
to the child process, so there's a window where we accept new entries
no matter what. This patch changes this by sending a boolean argument via
the command line indicating that we want to disable the Startupcache in this
process entirely. We send this when we didn't load a StartupCache off disk,
as this should be the only circumstance in which we're actually collecting
a substantial number of entries in content processes.
Differential Revision: https://phabricator.services.mozilla.com/D83400
This patch moves the remote type crash annotation code from RecvSetProcessSandbox() to
RecvRemoteType(), where we actually set the remote type. This matters because
RecvSetProcessSandbox() only happens once when the process is created. If the process
is a preallocated process, it will get its remote type updated later, so we need to
also update the annotation.
It seems odd that we were setting the remote type annotation in a method related to
the sandbox and not where we set the remote type. My only guess is that prior to
bug 1332522 RecvSetProcessSandbox() happened first, so maybe they wanted to make sure
the annotation was set as early as possible. At that point in time, the remote type
never changed, so it was okay to just set it wherever, as early as possible.
Anyways, after that bug, the first call to RecvRemoteType() happens earlier, so this
change is strictly better.
I also fixed a typo in ContentParent.
Differential Revision: https://phabricator.services.mozilla.com/D82625
This patch moves the remote type crash annotation code from RecvSetProcessSandbox() to
RecvRemoteType(), where we actually set the remote type. This matters because
RecvSetProcessSandbox() only happens once when the process is created. If the process
is a preallocated process, it will get its remote type updated later, so we need to
also update the annotation.
It seems odd that we were setting the remote type annotation in a method related to
the sandbox and not where we set the remote type. My only guess is that prior to
bug 1332522 RecvSetProcessSandbox() happened first, so maybe they wanted to make sure
the annotation was set as early as possible. At that point in time, the remote type
never changed, so it was okay to just set it wherever, as early as possible.
Anyways, after that bug, the first call to RecvRemoteType() happens earlier, so this
change is strictly better.
I also fixed a typo in ContentParent.
Differential Revision: https://phabricator.services.mozilla.com/D82625
CLOSED TREE
Backed out changeset 51d7c644a1e6 (bug 1650163)
Backed out changeset 3d2b6908447a (bug 1650163)
Backed out changeset 79141707d47b (bug 1650163)
The overall goal of this patch is to make the StartupCache accessible anywhere.
There's two main pieces to that equation:
1. Allowing it to be accessed off main thread, which means modifying the
mutex usage to ensure that all data accessed from non-main threads is
protected.
2. Allowing it to be accessed out of the chrome process, which means passing
a handle to a shared cache buffer down to child processes.
Number 1 is somewhat fiddly, but it's all generally straightforward work. I'll
hope that the comments and the code are sufficient to explain what's going on
there.
Number 2 has some decisions to be made:
- The first decision was to pass a handle to a frozen chunk of memory down to
all child processes, rather than passing a handle to an actual file. There's
two reasons for this: 1) since we want to compress the underlying file on
disk, giving that file to child processes would mean they have to decompress
it themselves, eating CPU time. 2) since they would have to decompress it
themselves, they would have to allocate the memory for the decompressed
buffers, meaning they cannot all simply share one big decompressed buffer.
- The drawback of this decision is that we have to load and decompress the
buffer up front, before we spawn any child processes. We attempt to
mitigate this by keeping track of all the entries that child processes
access, and only including those in the frozen decompressed shared buffer.
- We base our implementation of this approach off of the shared preferences
implementation. Hopefully I got all of the pieces to fit together
correctly. They seem to work in local testing and on try, but I think
they require a set of experienced eyes looking carefully at them.
- Another decision was whether to send the handles to the buffers over IPC or
via command line. We went with the command line approach, because the startup
cache would need to be accessed very early on in order to ensure we do not
read from any omnijars, and we could not make that work via IPC.
- Unfortunately this means adding another hard-coded FD, similar to
kPrefMapFileDescriptor. It seems like at the very least we need to rope all
of these together into one place, but I think that should be filed as a
follow-up?
Lastly, because this patch is a bit of a monster to review - first, thank you
for looking at it, and second, the reason we're invested in this is because we
saw a >10% improvement in cold startup times on reference hardware, with a p
value less than 0.01. It's still not abundantly clear how reference hardware
numbers translate to numbers on release, and they certainly don't translate
well to Nightly numbers, but it's enough to convince me that it's worth some
effort.
Depends on D78584
Differential Revision: https://phabricator.services.mozilla.com/D77635
The overall goal of this patch is to make the StartupCache accessible anywhere.
There's two main pieces to that equation:
1. Allowing it to be accessed off main thread, which means modifying the
mutex usage to ensure that all data accessed from non-main threads is
protected.
2. Allowing it to be accessed out of the chrome process, which means passing
a handle to a shared cache buffer down to child processes.
Number 1 is somewhat fiddly, but it's all generally straightforward work. I'll
hope that the comments and the code are sufficient to explain what's going on
there.
Number 2 has some decisions to be made:
- The first decision was to pass a handle to a frozen chunk of memory down to
all child processes, rather than passing a handle to an actual file. There's
two reasons for this: 1) since we want to compress the underlying file on
disk, giving that file to child processes would mean they have to decompress
it themselves, eating CPU time. 2) since they would have to decompress it
themselves, they would have to allocate the memory for the decompressed
buffers, meaning they cannot all simply share one big decompressed buffer.
- The drawback of this decision is that we have to load and decompress the
buffer up front, before we spawn any child processes. We attempt to
mitigate this by keeping track of all the entries that child processes
access, and only including those in the frozen decompressed shared buffer.
- We base our implementation of this approach off of the shared preferences
implementation. Hopefully I got all of the pieces to fit together
correctly. They seem to work in local testing and on try, but I think
they require a set of experienced eyes looking carefully at them.
- Another decision was whether to send the handles to the buffers over IPC or
via command line. We went with the command line approach, because the startup
cache would need to be accessed very early on in order to ensure we do not
read from any omnijars, and we could not make that work via IPC.
- Unfortunately this means adding another hard-coded FD, similar to
kPrefMapFileDescriptor. It seems like at the very least we need to rope all
of these together into one place, but I think that should be filed as a
follow-up?
Lastly, because this patch is a bit of a monster to review - first, thank you
for looking at it, and second, the reason we're invested in this is because we
saw a >10% improvement in cold startup times on reference hardware, with a p
value less than 0.01. It's still not abundantly clear how reference hardware
numbers translate to numbers on release, and they certainly don't translate
well to Nightly numbers, but it's enough to convince me that it's worth some
effort.
Depends on D78584
Differential Revision: https://phabricator.services.mozilla.com/D77635
The overall goal of this patch is to make the StartupCache accessible anywhere.
There's two main pieces to that equation:
1. Allowing it to be accessed off main thread, which means modifying the
mutex usage to ensure that all data accessed from non-main threads is
protected.
2. Allowing it to be accessed out of the chrome process, which means passing
a handle to a shared cache buffer down to child processes.
Number 1 is somewhat fiddly, but it's all generally straightforward work. I'll
hope that the comments and the code are sufficient to explain what's going on
there.
Number 2 has some decisions to be made:
- The first decision was to pass a handle to a frozen chunk of memory down to
all child processes, rather than passing a handle to an actual file. There's
two reasons for this: 1) since we want to compress the underlying file on
disk, giving that file to child processes would mean they have to decompress
it themselves, eating CPU time. 2) since they would have to decompress it
themselves, they would have to allocate the memory for the decompressed
buffers, meaning they cannot all simply share one big decompressed buffer.
- The drawback of this decision is that we have to load and decompress the
buffer up front, before we spawn any child processes. We attempt to
mitigate this by keeping track of all the entries that child processes
access, and only including those in the frozen decompressed shared buffer.
- We base our implementation of this approach off of the shared preferences
implementation. Hopefully I got all of the pieces to fit together
correctly. They seem to work in local testing and on try, but I think
they require a set of experienced eyes looking carefully at them.
- Another decision was whether to send the handles to the buffers over IPC or
via command line. We went with the command line approach, because the startup
cache would need to be accessed very early on in order to ensure we do not
read from any omnijars, and we could not make that work via IPC.
- Unfortunately this means adding another hard-coded FD, similar to
kPrefMapFileDescriptor. It seems like at the very least we need to rope all
of these together into one place, but I think that should be filed as a
follow-up?
Lastly, because this patch is a bit of a monster to review - first, thank you
for looking at it, and second, the reason we're invested in this is because we
saw a >10% improvement in cold startup times on reference hardware, with a p
value less than 0.01. It's still not abundantly clear how reference hardware
numbers translate to numbers on release, and they certainly don't translate
well to Nightly numbers, but it's enough to convince me that it's worth some
effort.
Depends on D78584
Differential Revision: https://phabricator.services.mozilla.com/D77635
In all those cases, the current nsISerialEventTarget is either the main thread or the MessageChannel's nsISerialEventTarget (since bug 1634846)
Differential Revision: https://phabricator.services.mozilla.com/D81966
This probably had logic issues before bug 1642991, but not security
issues (at worst, an array out of bounds which is a release assertion
that would crash the process in a safe way).
Differential Revision: https://phabricator.services.mozilla.com/D81596
The overall goal of this patch is to make the StartupCache accessible anywhere.
There's two main pieces to that equation:
1. Allowing it to be accessed off main thread, which means modifying the
mutex usage to ensure that all data accessed from non-main threads is
protected.
2. Allowing it to be accessed out of the chrome process, which means passing
a handle to a shared cache buffer down to child processes.
Number 1 is somewhat fiddly, but it's all generally straightforward work. I'll
hope that the comments and the code are sufficient to explain what's going on
there.
Number 2 has some decisions to be made:
- The first decision was to pass a handle to a frozen chunk of memory down to
all child processes, rather than passing a handle to an actual file. There's
two reasons for this: 1) since we want to compress the underlying file on
disk, giving that file to child processes would mean they have to decompress
it themselves, eating CPU time. 2) since they would have to decompress it
themselves, they would have to allocate the memory for the decompressed
buffers, meaning they cannot all simply share one big decompressed buffer.
- The drawback of this decision is that we have to load and decompress the
buffer up front, before we spawn any child processes. We attempt to
mitigate this by keeping track of all the entries that child processes
access, and only including those in the frozen decompressed shared buffer.
- We base our implementation of this approach off of the shared preferences
implementation. Hopefully I got all of the pieces to fit together
correctly. They seem to work in local testing and on try, but I think
they require a set of experienced eyes looking carefully at them.
- Another decision was whether to send the handles to the buffers over IPC or
via command line. We went with the command line approach, because the startup
cache would need to be accessed very early on in order to ensure we do not
read from any omnijars, and we could not make that work via IPC.
- Unfortunately this means adding another hard-coded FD, similar to
kPrefMapFileDescriptor. It seems like at the very least we need to rope all
of these together into one place, but I think that should be filed as a
follow-up?
Lastly, because this patch is a bit of a monster to review - first, thank you
for looking at it, and second, the reason we're invested in this is because we
saw a >10% improvement in cold startup times on reference hardware, with a p
value less than 0.01. It's still not abundantly clear how reference hardware
numbers translate to numbers on release, and they certainly don't translate
well to Nightly numbers, but it's enough to convince me that it's worth some
effort.
Depends on D78584
Differential Revision: https://phabricator.services.mozilla.com/D77635
The overall goal of this patch is to make the StartupCache accessible anywhere.
There's two main pieces to that equation:
1. Allowing it to be accessed off main thread, which means modifying the
mutex usage to ensure that all data accessed from non-main threads is
protected.
2. Allowing it to be accessed out of the chrome process, which means passing
a handle to a shared cache buffer down to child processes.
Number 1 is somewhat fiddly, but it's all generally straightforward work. I'll
hope that the comments and the code are sufficient to explain what's going on
there.
Number 2 has some decisions to be made:
- The first decision was to pass a handle to a frozen chunk of memory down to
all child processes, rather than passing a handle to an actual file. There's
two reasons for this: 1) since we want to compress the underlying file on
disk, giving that file to child processes would mean they have to decompress
it themselves, eating CPU time. 2) since they would have to decompress it
themselves, they would have to allocate the memory for the decompressed
buffers, meaning they cannot all simply share one big decompressed buffer.
- The drawback of this decision is that we have to load and decompress the
buffer up front, before we spawn any child processes. We attempt to
mitigate this by keeping track of all the entries that child processes
access, and only including those in the frozen decompressed shared buffer.
- We base our implementation of this approach off of the shared preferences
implementation. Hopefully I got all of the pieces to fit together
correctly. They seem to work in local testing and on try, but I think
they require a set of experienced eyes looking carefully at them.
- Another decision was whether to send the handles to the buffers over IPC or
via command line. We went with the command line approach, because the startup
cache would need to be accessed very early on in order to ensure we do not
read from any omnijars, and we could not make that work via IPC.
- Unfortunately this means adding another hard-coded FD, similar to
kPrefMapFileDescriptor. It seems like at the very least we need to rope all
of these together into one place, but I think that should be filed as a
follow-up?
Lastly, because this patch is a bit of a monster to review - first, thank you
for looking at it, and second, the reason we're invested in this is because we
saw a >10% improvement in cold startup times on reference hardware, with a p
value less than 0.01. It's still not abundantly clear how reference hardware
numbers translate to numbers on release, and they certainly don't translate
well to Nightly numbers, but it's enough to convince me that it's worth some
effort.
Depends on D78584
Differential Revision: https://phabricator.services.mozilla.com/D77635
This switches the `nsIContent{Parent,Child}` interface to be
`nsIDOMProcess{Parent,Child}`, and also implements it on
`InProcess{Parent,Child}`, along with the `ProcessActor` interface.
Differential Revision: https://phabricator.services.mozilla.com/D80582
This moves it near the cross-process `PContent` actor, and makes it more clear
that this actor is only intended to be used for DOM things.
Differential Revision: https://phabricator.services.mozilla.com/D80581
This also fixes a bug where we were setting mOriginalUriString in docshell before InternalLoad (which clears it), instead of after.
Differential Revision: https://phabricator.services.mozilla.com/D80110
This switches the `nsIContent{Parent,Child}` interface to be
`nsIDOMProcess{Parent,Child}`, and also implements it on
`InProcess{Parent,Child}`, along with the `ProcessActor` interface.
Differential Revision: https://phabricator.services.mozilla.com/D80582
This moves it near the cross-process `PContent` actor, and makes it more clear
that this actor is only intended to be used for DOM things.
Differential Revision: https://phabricator.services.mozilla.com/D80581
This also fixes a bug where we were setting mOriginalUriString in docshell before InternalLoad (which clears it), instead of after.
Differential Revision: https://phabricator.services.mozilla.com/D80110
SPI_GETFLATMENU uses the newly-added WinContentSystemParameters and adds
the ability to update theme-related variables when they change.
Differential Revision: https://phabricator.services.mozilla.com/D80071
Introducing FOGIPC, the central clearinghouse for the C++ layer between
PContent and FOG's Rust impl.
Gotta add tests.
Differential Revision: https://phabricator.services.mozilla.com/D79742
Temporarily on PContent instead of managed by PBackground, there's one
parentbound message for occasionally uplifting Glean data from child processes
and one childbound message for forcing the immediate flush of Glean data in the
async return.
Can't write gtests for this as ContentChild and ContentParent include things
that aren't present in gtest.
Differential Revision: https://phabricator.services.mozilla.com/D78077
Introducing FOGIPC, the central clearinghouse for the C++ layer between
PContent and FOG's Rust impl.
Gotta add tests.
Differential Revision: https://phabricator.services.mozilla.com/D79742
Temporarily on PContent instead of managed by PBackground, there's one
parentbound message for occasionally uplifting Glean data from child processes
and one childbound message for forcing the immediate flush of Glean data in the
async return.
Can't write gtests for this as ContentChild and ContentParent include things
that aren't present in gtest.
Differential Revision: https://phabricator.services.mozilla.com/D78077
We can just use BrowsingContext::BrowserId directly, so it's unnecessary to have
the field on nsFrameLoaderOwner as well.
This also makes it so that we only ever generate browser IDs in
BrowsingContext::CreatedDetached.
Differential Revision: https://phabricator.services.mozilla.com/D80121
This adds a `browserId` property to all browsing contexts. This ID is the same
for the entire tree of contexts inside a frame element. Each new top-level
context created for a given frame also inherits this ID. This allows identifying
the frame element for a given browsing context.
Originally authored by :mossop in D56245.
Differential Revision: https://phabricator.services.mozilla.com/D77911
This adds a `browserId` property to all browsing contexts. This ID is the same
for the entire tree of contexts inside a frame element. Each new top-level
context created for a given frame also inherits this ID. This allows identifying
the frame element for a given browsing context.
Originally authored by :mossop in D56245.
Differential Revision: https://phabricator.services.mozilla.com/D77911
There are a number of system parameters that return simple floats and bools
and are just different forms of system parameter query.
This introduces a new singleton and IPDL calls to send these values from parent
to content processes and cache them in content.
I started with these 2 variables because their values don't go stale. In a
later changeset, I will add more logic to invalidate cached values that go
stale, such as for the SPI_GETFLATMENU metric.
Differential Revision: https://phabricator.services.mozilla.com/D76639
This patch will
- remove `MediaControlKeysEvent` and use `MediaControlKey` to replace it
- rename names for all `MediaControlKey` related methods, functions, classes and descriptions
The advantage of doing so are
- remove the duplicated type so that we only need to maintain `MediaControlKey`
Differential Revision: https://phabricator.services.mozilla.com/D78140
Adds a `browserId` property to all browsing contexts which the same for the
entire tree of contexts inside a frame element. If a new top-level context is
created for the frame then it is assigned the same value.
This allows identifying the frame element for a given browsing context.
Currently this is only done for XUL frame elements (browser/iframe). Not sure
if we want this for others.
Differential Revision: https://phabricator.services.mozilla.com/D56245
Adds a `browserId` property to all browsing contexts which the same for the
entire tree of contexts inside a frame element. If a new top-level context is
created for the frame then it is assigned the same value.
This allows identifying the frame element for a given browsing context.
Currently this is only done for XUL frame elements (browser/iframe). Not sure
if we want this for others.
Differential Revision: https://phabricator.services.mozilla.com/D56245
Valentin Gosu
sefeng
Jean-Yves Avenard
Emilio Cobos Álvarez
Dan Glastonbury
Tom Tung
Nika Layzell
Kris Maglione
Simon Giesecke
Nico Grunbaum
Doug Thayer
Luca Greco
Henri Sivonen
Razvan Maries
Peter Van der Beken
Agi Sferro
Andrea Marchesini
Bogdan Tara
Olli Pettay
Mihai Alexandru Michis
Csoregi Natalia
Jed Davis
Andrew McCreight
Chris Martin
Randell Jesup
Karl Tomlinson
David Teller
alwu
Butkovits Atila
Narcis Beleuzu
Noemi Erli
Matt Woodrow
Cosmin Sabou
Chris H-C
Andreas Farre
Kashav Madan
Nicholas Nethercote
Dave Townsend
Dorel Luca
Alexis Beingessner
Sebastian Streich
nchevobbe