This patch adds a UnstrippedURI into the LoadInfo. This attribute
represents the channel's URI has been stripped if this attributes is not
a nullptr.
Having this attribute allows us to be able to revert the query stripping
in the case where the loading channel is in the content blocking allow
list in the parent process.
In addition, this patch removes the main thread assertion in URIUtils
given that we've made the URL construction thread-safe. This will allow
us to be able to use nsIURI directly in ParentLoadInfoForwarderArgs.
Differential Revision: https://phabricator.services.mozilla.com/D116108
To collect session storage data for session store, we make it possible
to query the background session storage managar for data.
Depends on D111432
Differential Revision: https://phabricator.services.mozilla.com/D111433
To collect session storage data for session store, we make it possible
to query the background session storage managar for data.
Depends on D111432
Differential Revision: https://phabricator.services.mozilla.com/D111433
This is almost certainly a very small optimization, and likely won't address
the frequency of hangs from bug 1677509. However, it still should be an
improvement, and will work on anything Vista or later.
We observed as part of trying to diagnose the somewhat mysterious bug 1677509
that sometimes multiple messages would be queued, and yet the IPC I/O thread
would go idle in between servicing them in GetQueuedCompletionStatusEx. Given
that we send frequent sync ipc messages for mouse move events, it seems prudent
to be able to service multiple at a time.
Differential Revision: https://phabricator.services.mozilla.com/D114287
This change adds the ground work to share content provided by the JS engine of
the Parent process to initialize the JS engine of other threads and Content
processes.
The singleton class xpc::SelfHostedShmem is used to wrap the logic behind
holding the memory. The memory is initialized with `InitFromParent` or
`InitFromChild`. The memory is accessible using either the `Content` or
`Handle`.
The shared memory is transfered through the command line using
`mozilla::ipc::ExportSharedJSInit` and read using
`mozilla::ipc::ImportSharedJSInit` functions. The command line is used, as we
need the shared memory to be avilable for the JS engine initialization. The
command line is composed of a single command named `-jsInit` which is followed
by the handle (on Windows) and the length of the shared content.
The memory associated with the shared memory is cleared in `ShutdownXPCOM` after
closing all threads, and shuting down the JS engine. This is necessary as we
expect the JS engine to borrow content from the shared memory.
Differential Revision: https://phabricator.services.mozilla.com/D110576
We'd like to know if there are any problems with starving content processes
of cleaning up memory in a timely way. Add some telemetry to get a sense of
this.
Differential Revision: https://phabricator.services.mozilla.com/D113275
In order to avoid concurrency issues when dumping or to be able to have a ccov report per process, when GCOV_CHILD_PREFIX is set, set child processes' GCOV_PREFIX to GCOV_CHILD_PREFIX + child process PID
Differential Revision: https://phabricator.services.mozilla.com/D114239
This both helps IDE integration and will help avoid build issues which would've
otherwise cropped up when adding new files to the directory for bug 1706374.
Differential Revision: https://phabricator.services.mozilla.com/D112764
`High` priority is being used for vsync tasks, so we should rename it to
make it clear, and renaming it also makes our priority naming less
confusing.
Differential Revision: https://phabricator.services.mozilla.com/D109536
Eliminates the NPAPI plugin process type from the GeckoChildProcess enum as part of NPAPI removal. In order to avoid altering enum values when updating the process list, the GECKO_PROCESS_TYPE macro has been updated to include the desired enum value. We want to resist altering the values as they need to be consistent e.g. in telemetry reports.
We also remove plugins from adjacent spots that need to maintain consistency with GeckoChildProcess -- most notably the nsICrashService.
Differential Revision: https://phabricator.services.mozilla.com/D108689
Removes Windows NPAPI process sandboxing code, including the code to establish a viable temp directory that was accessible by the sandboxed process.
Differential Revision: https://phabricator.services.mozilla.com/D108688
Removes async (windowless) NPAPI plugin rendering methods used to render a plugin to an offscreen surface in the GPU process. None of this code is used since we have removed all NPAPI plugin support.
Differential Revision: https://phabricator.services.mozilla.com/D107152
This is the first of two patches in this series that removes a large amount of now dead code from dom/plugins as part of removing all NPAPI plugin support. This patch removes re-entrancy guards we have for Windows OnPaint messages, as the guards were only needed for windowed plugins.
Differential Revision: https://phabricator.services.mozilla.com/D107144
Removes the mac plugin_interposer (and the related NSCursorInfo behavior), as part of removing all of NPAPI plugin support, since it has no other clients.
Differential Revision: https://phabricator.services.mozilla.com/D107142
Removes the PPluginSurface actor used for windowed plugins, as part of removing all of NPAPI plugin support. SharedDIB is then unused and is also removed.
Differential Revision: https://phabricator.services.mozilla.com/D107140
`High` priority is being used for vsync tasks, so we should rename it to
make it clear, and renaming it also makes our priority naming less
confusing.
Differential Revision: https://phabricator.services.mozilla.com/D109536
Eliminates the NPAPI plugin process type from the GeckoChildProcess enum as part of NPAPI removal. In order to avoid altering enum values when updating the process list, the GECKO_PROCESS_TYPE macro has been updated to include the desired enum value. We want to resist altering the values as they need to be consistent e.g. in telemetry reports.
We also remove plugins from adjacent spots that need to maintain consistency with GeckoChildProcess -- most notably the nsICrashService.
Differential Revision: https://phabricator.services.mozilla.com/D108689
Removes Windows NPAPI process sandboxing code, including the code to establish a viable temp directory that was accessible by the sandboxed process.
Differential Revision: https://phabricator.services.mozilla.com/D108688
Removes async (windowless) NPAPI plugin rendering methods used to render a plugin to an offscreen surface in the GPU process. None of this code is used since we have removed all NPAPI plugin support.
Differential Revision: https://phabricator.services.mozilla.com/D107152
This is the first of two patches in this series that removes a large amount of now dead code from dom/plugins as part of removing all NPAPI plugin support. This patch removes re-entrancy guards we have for Windows OnPaint messages, as the guards were only needed for windowed plugins.
Differential Revision: https://phabricator.services.mozilla.com/D107144
Removes the mac plugin_interposer (and the related NSCursorInfo behavior), as part of removing all of NPAPI plugin support, since it has no other clients.
Differential Revision: https://phabricator.services.mozilla.com/D107142
Removes the PPluginSurface actor used for windowed plugins, as part of removing all of NPAPI plugin support. SharedDIB is then unused and is also removed.
Differential Revision: https://phabricator.services.mozilla.com/D107140
This patch exposes SharedMemoryBasic::Unmap for use by callers to allow
one to unmap memory out of our address space without destroying the
SharedMemoryBasic object itself. This will be used by later patches in
this series.
Differential Revision: https://phabricator.services.mozilla.com/D109438
This patch exposes SharedMemoryBasic::Unmap for use by callers to allow
one to unmap memory out of our address space without destroying the
SharedMemoryBasic object itself. This will be used by later patches in
this series.
Differential Revision: https://phabricator.services.mozilla.com/D109438
This patch exposes SharedMemoryBasic::Unmap for use by callers to allow
one to unmap memory out of our address space without destroying the
SharedMemoryBasic object itself. This will be used by later patches in
this series.
Differential Revision: https://phabricator.services.mozilla.com/D109438
When setting up calls to `sendmsg` for IPC on Unix systems, we generate
`iovec`s for the entire message or until the `IOV_MAX` limit is reached,
whichever comes first. However, messages can be very large (up to 256
MiB currently), while the OS socket buffer is relatively small (8KiB on
macOS and FreeBSD, ~200KiB on Linux).
This patch detects the socket buffer size with the `SO_SNDBUF` socket
option and cuts off the `iovec` array after it's reached; it also adjusts
the Linux sandbox policy to allow reading that value in all processes.
On my test machines this increases throughput on large messages by about
2.5x on macOS (from ~0.3 to ~0.7 GB/s), but on Linux the improvement is
only about 5% (most of the running time is spent elsewhere).
Differential Revision: https://phabricator.services.mozilla.com/D105852
Currently we walk through the entire list of not-yet-written IPC buffers
when building the gathered I/O list for `sendmsg`, to determine the
total remaining length of the messages, even after reaching the OS's
limit on how many `iovec`s it will accept in one call.
This patch halts the iteration when we reach the `iovec` limit, because
we don't need the exact length; it's sufficient to know whether the
entire message was written, which is impossible in that case.
This increases throughput on large messages by about 7x on macOS (from
~0.04 to ~0.3 GB/s) and 1.7x on Linux (from ~0.3 to ~0.5 GB/s), on my
test machines. The effect is more significant on macOS because its
smaller socket buffer size (8kB vs. ~200kB) means we spend more time
setting up the syscall per unit data copied; see also the next patch.
Differential Revision: https://phabricator.services.mozilla.com/D105851
This patch adds a flag 'needForCheckingAntiTrackingHeuristic' in
loadInfo. This flag will be used for deciding if we need to check the
AntiTracking heuristic after the channel has been classified.
Differential Revision: https://phabricator.services.mozilla.com/D107047
Note that this patch only transforms the use of the nsDataHashtable type alias
to a directly equivalent use of nsTHashMap. It does not change the specification
of the hash key type to make use of the key class deduction that nsTHashMap
allows for in some cases. That can be done in a separate step, but requires more
attention.
Differential Revision: https://phabricator.services.mozilla.com/D106008
PGamepadEventChannelParent will need to send an async message back to the
child with info about the new shared memory region upon creation.
The IPDL channel is not ready during allocation, so we need to defer
registering the actor with GamepadPlatformService until the IPDL
"RecvConstructor" message so the channel will be available.
This is just a straight refactor to prepare for the upcoming change.
Differential Revision: https://phabricator.services.mozilla.com/D105127
PGamepadEventChannelParent will need to send an async message back to the
child with info about the new shared memory region upon creation.
The IPDL channel is not ready during allocation, so we need to defer
registering the actor with GamepadPlatformService until the IPDL
"RecvConstructor" message so the channel will be available.
This is just a straight refactor to prepare for the upcoming change.
Differential Revision: https://phabricator.services.mozilla.com/D105127
PGamepadEventChannelParent will need to send an async message back to the
child with info about the new shared memory region upon creation.
The IPDL channel is not ready during allocation, so we need to defer
registering the actor with GamepadPlatformService until the IPDL
"RecvConstructor" message so the channel will be available.
This is just a straight refactor to prepare for the upcoming change.
Differential Revision: https://phabricator.services.mozilla.com/D105127
This patch wants to solve several quirks around the shutdown terminator.
- Use the same shutdown phase definitions in AppShutdown and nsTerminator. This touches quite a few files.
- Ensure that the terminator phase shift is handled before any shutdown observer notifications are sent and reduce its heartbeat duration.
- Add missing phases to the shutdown telemetry.
Please note that this changes the unit of "tick" to 100ms rather than 1s.
As a side effect, we also remove the obsolete "shutdown-persist" context.
While the existing test coverage continues to prove the most important functions, we acknowledge the wish for better test coverage with [[ https://bugzilla.mozilla.org/show_bug.cgi?id=1693966 | bug 1693966 ]].
Differential Revision: https://phabricator.services.mozilla.com/D103626
This patch wants to solve several quirks around the shutdown terminator.
- Use the same shutdown phase definitions in AppShutdown and nsTerminator. This touches quite a few files.
- Ensure that the terminator phase shift is handled before any shutdown observer notifications are sent and reduce its heartbeat duration.
- Add missing phases to the shutdown telemetry.
Please note that this changes the unit of "tick" to 100ms rather than 1s.
As a side effect, we also remove the obsolete "shutdown-persist" context.
While the existing test coverage continues to prove the most important functions, we acknowledge the wish for better test coverage with [[ https://bugzilla.mozilla.org/show_bug.cgi?id=1693966 | bug 1693966 ]].
Differential Revision: https://phabricator.services.mozilla.com/D103626
This makes the naming more consistent with other functions called
Insert and/or Update. Also, it removes the ambiguity whether
Put expects that an entry already exists or not, in particular because
it differed from nsTHashtable::PutEntry in that regard.
Differential Revision: https://phabricator.services.mozilla.com/D105473
In bug 1691415 we're getting failures to deserialize. It would be
nice to move these closer to the source so that we can better understand
what's going on.
Differential Revision: https://phabricator.services.mozilla.com/D105688
We know that some GV installations (particularly but not exlcusively Focus) are
failing to load `libxul.so` during early Gecko bootstrapping. Unfortunately
a boolean pass/fail result is not giving us sufficient information to be able to
properly troubleshoot this problem.
This patch adds `mozilla::Result`-based return values to `XPCOMGlueLoad` and
`GetBootstrap` in an effort to produce more actionable information about these
failures.
We include either a `nsresult` or, if the failure is rooted in a dynamic linker
failure, appropriate platform-specific error information:
* On Unix-based platforms, a `UniqueFreePtr<char>` containing the string from `dlerror(3)`;
* On Windows, the Win32 `DWORD` error code from `GetLastError()`.
For non-Android platforms, I updated them to handle the new return type, but
otherwise did not make any further changes.
For Android, we include the error information in the message string that we pass
into the Java `Exception` that is subsequently thrown.
Differential Revision: https://phabricator.services.mozilla.com/D104263
This point in the code is the end of receiving a message, not the start
(note the `if (partial) { break; }` above), so it should be marked
accordingly. The profiler frontend is expecting the end marker;
currently two of the four reported time intervals are `unknown` on
Windows, and this patch fixes that.
(Recording the receiving start time is complicated, because we don't
have a `Messsage` object until we've read the buffer with the (end of
the) header, and it might make more sense to timestamp it before the
first receive operation. Currently, neither channel implementation
attempts this.)
Differential Revision: https://phabricator.services.mozilla.com/D105094
Currently, we add an `eSending`/`TransferStart` marker every time we
send data as part of a message, rather than only the first time. The
profiler frontend appears to ignore the extra markers (the displayed time
intervals look reasonable), but it's wasteful: on large messages it can
consume enough CPU time to appear in the profile itself.
Differential Revision: https://phabricator.services.mozilla.com/D105093
There are no code changes, only #include changes.
It was a fairly mechanical process: Search for all "AUTO_PROFILER_LABEL", and in each file, if only labels are used, convert "GeckoProfiler.h" into "ProfilerLabels.h" (or just add that last one where needed).
In some files, there were also some marker calls but no other profiler-related calls, in these cases "GeckoProfiler.h" was replaced with both "ProfilerLabels.h" and "ProfilerMarkers.h", which still helps in reducing the use of the all-encompassing "GeckoProfiler.h".
Differential Revision: https://phabricator.services.mozilla.com/D104588
The current set of cases where a nsIInputStream is directly serialized over IPC
is fairly limited, and includes cases where the IPDL struct may be directly
stored within a content process, having the nsIInputStream left unused.
By switching this serialization to DelayedStart, we can avoid performing
unnecessary streaming copies of IPC data when sending postdata streams related
to session history and document navigation, while also avoiding issues like this
coming up again due to delayed start being the default.
Differential Revision: https://phabricator.services.mozilla.com/D101804
When aDelayedStart is specified, if the created IPCStream contains an internal
IPC stream actor, an actor is used under the hood to send raw data between
processes when needed. This is usually done to reduce overhead in cases where
the target process may not use the nsIInputStream immediately, if at all.
By switching to using RemoteLazyInputStream when sending DelayedStart actors
from parent to content, the amount of data sent in the initial payload is
reduced even further, and the stream is optimized to allow sending it back to
the parent process without streaming the data through the content process again.
Normal delayed start streams are still used when sending payloads from other
processes, as RemoteLazyInputStream is only supported for nsIInputStreams
originating in the parent process.
Differential Revision: https://phabricator.services.mozilla.com/D101803
Previously, we would apply the InputStreamLengthWrapper before
DelayedStartInputStream, which meant that a stream serialized with aDelayedStart
would not correctly implement nsIInputStreamLength. By inverting the order of
these wrappers, the nsIInputStreamLength implementation is visible, without
impacting the functionality of the DelayedStartInputStream wrapper.
Differential Revision: https://phabricator.services.mozilla.com/D101802
Without the other patches in this series, this test fails with both with and
without Fission enabled, for two different reasons.
With Fission disabled, the second reload request appears as empty, due to us
being unable to rewind the postData nsIInputStream. With Fission enabled, the
second reload request causes crashes due to the nsMIMEInputStream's invariant of
requiring a seekable stream is invalidated, causing the nsICloneableInputStream
implementation to misbehave.
Differential Revision: https://phabricator.services.mozilla.com/D101800
The current set of cases where a nsIInputStream is directly serialized over IPC
is fairly limited, and includes cases where the IPDL struct may be directly
stored within a content process, having the nsIInputStream left unused.
By switching this serialization to DelayedStart, we can avoid performing
unnecessary streaming copies of IPC data when sending postdata streams related
to session history and document navigation, while also avoiding issues like this
coming up again due to delayed start being the default.
Differential Revision: https://phabricator.services.mozilla.com/D101804
When aDelayedStart is specified, if the created IPCStream contains an internal
IPC stream actor, an actor is used under the hood to send raw data between
processes when needed. This is usually done to reduce overhead in cases where
the target process may not use the nsIInputStream immediately, if at all.
By switching to using RemoteLazyInputStream when sending DelayedStart actors
from parent to content, the amount of data sent in the initial payload is
reduced even further, and the stream is optimized to allow sending it back to
the parent process without streaming the data through the content process again.
Normal delayed start streams are still used when sending payloads from other
processes, as RemoteLazyInputStream is only supported for nsIInputStreams
originating in the parent process.
Differential Revision: https://phabricator.services.mozilla.com/D101803
Previously, we would apply the InputStreamLengthWrapper before
DelayedStartInputStream, which meant that a stream serialized with aDelayedStart
would not correctly implement nsIInputStreamLength. By inverting the order of
these wrappers, the nsIInputStreamLength implementation is visible, without
impacting the functionality of the DelayedStartInputStream wrapper.
Differential Revision: https://phabricator.services.mozilla.com/D101802
Without the other patches in this series, this test fails with both with and
without Fission enabled, for two different reasons.
With Fission disabled, the second reload request appears as empty, due to us
being unable to rewind the postData nsIInputStream. With Fission enabled, the
second reload request causes crashes due to the nsMIMEInputStream's invariant of
requiring a seekable stream is invalidated, causing the nsICloneableInputStream
implementation to misbehave.
Differential Revision: https://phabricator.services.mozilla.com/D101800
The current set of cases where a nsIInputStream is directly serialized over IPC
is fairly limited, and includes cases where the IPDL struct may be directly
stored within a content process, having the nsIInputStream left unused.
By switching this serialization to DelayedStart, we can avoid performing
unnecessary streaming copies of IPC data when sending postdata streams related
to session history and document navigation, while also avoiding issues like this
coming up again due to delayed start being the default.
Differential Revision: https://phabricator.services.mozilla.com/D101804
When aDelayedStart is specified, if the created IPCStream contains an internal
IPC stream actor, an actor is used under the hood to send raw data between
processes when needed. This is usually done to reduce overhead in cases where
the target process may not use the nsIInputStream immediately, if at all.
By switching to using RemoteLazyInputStream when sending DelayedStart actors
from parent to content, the amount of data sent in the initial payload is
reduced even further, and the stream is optimized to allow sending it back to
the parent process without streaming the data through the content process again.
Normal delayed start streams are still used when sending payloads from other
processes, as RemoteLazyInputStream is only supported for nsIInputStreams
originating in the parent process.
Differential Revision: https://phabricator.services.mozilla.com/D101803
Previously, we would apply the InputStreamLengthWrapper before
DelayedStartInputStream, which meant that a stream serialized with aDelayedStart
would not correctly implement nsIInputStreamLength. By inverting the order of
these wrappers, the nsIInputStreamLength implementation is visible, without
impacting the functionality of the DelayedStartInputStream wrapper.
Differential Revision: https://phabricator.services.mozilla.com/D101802
Without the other patches in this series, this test fails with both with and
without Fission enabled, for two different reasons.
With Fission disabled, the second reload request appears as empty, due to us
being unable to rewind the postData nsIInputStream. With Fission enabled, the
second reload request causes crashes due to the nsMIMEInputStream's invariant of
requiring a seekable stream is invalidated, causing the nsICloneableInputStream
implementation to misbehave.
Differential Revision: https://phabricator.services.mozilla.com/D101800
Previously, there was undefined behaviour when validating enum values in
EnumSerializer, which were actually invalid (which was hit during fuzzing, e.g.),
because the invalid integral value was cast to the enum type for comparison.
This patch changes the comparison to cast the valid values to their integral
values instead and compare those.
Differential Revision: https://phabricator.services.mozilla.com/D103449
The current set of cases where a nsIInputStream is directly serialized over IPC
is fairly limited, and includes cases where the IPDL struct may be directly
stored within a content process, having the nsIInputStream left unused.
By switching this serialization to DelayedStart, we can avoid performing
unnecessary streaming copies of IPC data when sending postdata streams related
to session history and document navigation, while also avoiding issues like this
coming up again due to delayed start being the default.
Differential Revision: https://phabricator.services.mozilla.com/D101804
When aDelayedStart is specified, if the created IPCStream contains an internal
IPC stream actor, an actor is used under the hood to send raw data between
processes when needed. This is usually done to reduce overhead in cases where
the target process may not use the nsIInputStream immediately, if at all.
By switching to using RemoteLazyInputStream when sending DelayedStart actors
from parent to content, the amount of data sent in the initial payload is
reduced even further, and the stream is optimized to allow sending it back to
the parent process without streaming the data through the content process again.
Normal delayed start streams are still used when sending payloads from other
processes, as RemoteLazyInputStream is only supported for nsIInputStreams
originating in the parent process.
Differential Revision: https://phabricator.services.mozilla.com/D101803
Previously, we would apply the InputStreamLengthWrapper before
DelayedStartInputStream, which meant that a stream serialized with aDelayedStart
would not correctly implement nsIInputStreamLength. By inverting the order of
these wrappers, the nsIInputStreamLength implementation is visible, without
impacting the functionality of the DelayedStartInputStream wrapper.
Differential Revision: https://phabricator.services.mozilla.com/D101802
Without the other patches in this series, this test fails with both with and
without Fission enabled, for two different reasons.
With Fission disabled, the second reload request appears as empty, due to us
being unable to rewind the postData nsIInputStream. With Fission enabled, the
second reload request causes crashes due to the nsMIMEInputStream's invariant of
requiring a seekable stream is invalidated, causing the nsICloneableInputStream
implementation to misbehave.
Differential Revision: https://phabricator.services.mozilla.com/D101800
Applying a bulk filter on accessibles in content process allows us to avoid a potentially large (and variable) number of IPC sync calls to retrieve the accessible names. I chose to implement this as a "post filter" and not to actually do the entire search in content because it would cause a lot of duplication of code for non-IPC searching, and we wouldn't have the flexibility to combine a text search with any arbitrary search key as the API requires.
I also generalized the RangeTypes.h header to PlatformExtTypes so it can be used to define filter types as well.
Differential Revision: https://phabricator.services.mozilla.com/D100730
Bug 1583109 introduced new function templates StringJoin and StringJoinAppend.
These are now used to replace several custom loops across the codebase that
implement string-joining algorithms to simplify the code.
Differential Revision: https://phabricator.services.mozilla.com/D98750
Bug 1583109 introduced new function templates StringJoin and StringJoinAppend.
These are now used to replace several custom loops across the codebase that
implement string-joining algorithms to simplify the code.
Differential Revision: https://phabricator.services.mozilla.com/D98750
Passing a union here allows us to reuse code and trim some code which was
duplicated to handle the different NodeId formats. This also consolidates the
former `NodeId` and `NodeIdData` structures into a new structure (working name
`NodeIdParts`) which represents parts that will later be converted to a string
based NodeId.
Differential Revision: https://phabricator.services.mozilla.com/D93569
This moves parts of IPCMessageUtils.h to two new header files and adapts
the include directives as necessary. The new header files are:
- EnumSerializer.h, which defines the templates for enum serializers
- IPCMessageUtilsSpecializations.h, which defines template specializations
of ParamTraits with extra dependencies (building upon both IPCMessageUtils.h
and EnumSerializer.h)
This should minimize the dependencies pulled in by every consumer of
IPCMessageUtils.h
Differential Revision: https://phabricator.services.mozilla.com/D94459
### Story
While the exisiting top browsing context is replaced, SessionStorage relies on
itself been propagated by SessionStore. However, this has been disabled in
SessionHistory in the parent process.
Therefore, we need to propagate SessionStorage data by propagating
BackgroundSessionStorageManager.
### Notes
This patch assumes that the target top-level browsing context shouldn't have
been registered to BackgroundSessionStorageManager. If this can happen, we will
either need to merge SessionStorage data into it or find a proper (earlier)
place to update sManagers.
### Test Plan
Test: D97763
Try: https://treeherder.mozilla.org/jobs?repo=try&revision=2acc7b393fb80b640f4fbe3ade1da7dd440c380e&selectedTaskRun=KK6XhR-sQuqv5lcntVLc2w.0
Differential Revision: https://phabricator.services.mozilla.com/D98082
Classes that inherit from DiscardableRunnable are only promising that it is OK
for Run() to be skipped, rather than promising that Cancel() is effective.
Differential Revision: https://phabricator.services.mozilla.com/D98117
To allow `requestAnimationFrame()` and similar things to run at monitor
speed if there is only a window-specific vsyncsource available.
This is the case for Wayland and, in the future, EGL/X11. Other backends
may opt for window specific vsyncsources as well at some point.
The idea is to, instead of using global vsync objects, expose a vsyncsource
from nsWindow and use it for refresh drivers. For the content process, move
VsyncChild to BrowserChild, so for each Browserchild there is only one
VsyncChild to which all refresh drivers connect.
IPC in managed either by PBrowser or PBackground. Right now, PBrowser is
only used on Wayland, as both PBrowser and the Wayland vsyncsource run
on the main thread. Other backends keep using the background thread for
now.
While at it, make it so that we constantly update the refresh rate. This
is necessary for Wayland, but also on other platforms variable refresh rates
are increasingly common. Do that by transimitting the vsync rate `SendNotify()`.
How to test:
- run the Wayland backend
- enable `widget.wayland_vsync.enabled`
- optionally: disable `privacy.reduceTimerPrecision`
- run `vsynctester.com` or `testufo.com`
Expected results:
Instead of fixed 60Hz, things should update at monitor refresh rate -
e.g. 144Hz
Original patch by Kenny Levinsen.
Depends on D98254
Differential Revision: https://phabricator.services.mozilla.com/D93173
When using an x64 GMP child process with an arm64 parent process on arm64 Mac's, use a 16k Shmem pagesize in the child process.
Differential Revision: https://phabricator.services.mozilla.com/D98241
To allow `requestAnimationFrame()` and similar things to run at monitor
speed if there is only a window-specific vsyncsource available.
This is the case for Wayland and, in the future, EGL/X11. Other backends
may opt for window specific vsyncsources as well at some point.
The idea is to, instead of using global vsync objects, expose a vsyncsource
from nsWindow and use it for refresh drivers. For the content process, move
VsyncChild to BrowserChild, so for each Browserchild there is only one
VsyncChild to which all refresh drivers connect.
IPC in managed either by PBrowser or PBackground. Right now, PBrowser is
only used on Wayland, as both PBrowser and the Wayland vsyncsource run
on the main thread. Other backends keep using the background thread for
now.
While at it, make it so that we constantly update the refresh rate. This
is necessary for Wayland, but also on other platforms variable refresh rates
are increasingly common. Do that by transimitting the vsync rate `SendNotify()`.
How to test:
- run the Wayland backend
- enable `widget.wayland_vsync.enabled`
- optionally: disable `privacy.reduceTimerPrecision`
- run `vsynctester.com` or `testufo.com`
Expected results:
Instead of fixed 60Hz, things should update at monitor refresh rate -
e.g. 144Hz
Original patch by Kenny Levinsen.
Differential Revision: https://phabricator.services.mozilla.com/D93173
To allow `requestAnimationFrame()` and similar things to run at monitor
speed if there is only a window-specific vsyncsource available.
This is the case for Wayland and, in the future, EGL/X11. Other backends
may opt for window specific vsyncsources as well at some point.
The idea is to, instead of using global vsync objects, expose a vsyncsource
from nsWindow and use it for refresh drivers. For the content process, move
VsyncChild to BrowserChild, so for each Browserchild there is only one
VsyncChild to which all refresh drivers connect.
IPC in managed either by PBrowser or PBackground. Right now, PBrowser is
only used on Wayland, as both PBrowser and the Wayland vsyncsource run
on the main thread. Other backends keep using the background thread for
now.
While at it, make it so that we constantly update the refresh rate. This
is necessary for Wayland, but also on other platforms variable refresh rates
are increasingly common. Do that by transimitting the vsync rate `SendNotify()`.
How to test:
- run the Wayland backend
- enable `widget.wayland_vsync.enabled`
- optionally: disable `privacy.reduceTimerPrecision`
- run `vsynctester.com` or `testufo.com`
Expected results:
Instead of fixed 60Hz, things should update at monitor refresh rate -
e.g. 144Hz
Original patch by Kenny Levinsen.
Differential Revision: https://phabricator.services.mozilla.com/D93173
To allow `requestAnimationFrame()` and similar things to run at monitor
speed if there is only a window-specific vsyncsource available.
This is the case for Wayland and, in the future, EGL/X11. Other backends
may opt for window specific vsyncsources as well at some point.
The idea is to, instead of using global vsync objects, expose a vsyncsource
from nsWindow and use it for refresh drivers. For the content process, move
VsyncChild to BrowserChild, so for each Browserchild there is only one
VsyncChild to which all refresh drivers connect.
IPC in managed either by PBrowser or PBackground. Right now, PBrowser is
only used on Wayland, as both PBrowser and the Wayland vsyncsource run
on the main thread. Other backends keep using the background thread for
now.
While at it, make it so that we constantly update the refresh rate. This
is necessary for Wayland, but also on other platforms variable refresh rates
are increasingly common. When using PVsync, limit updates to once in every
250ms in order to minimize overhead while still updating fast.
How to test:
- run the Wayland backend
- enable `widget.wayland_vsync.enabled`
- optionally: disable `privacy.reduceTimerPrecision`
- run `vsynctester.com` or `testufo.com`
Expected results:
Instead of fixed 60Hz, things should update at monitor refresh rate -
e.g. 144Hz
Original patch by Kenny Levinsen.
Differential Revision: https://phabricator.services.mozilla.com/D93173
To allow `requestAnimationFrame()` and similar things to run at monitor
speed if there is only a window-specific vsyncsource available.
This is the case for Wayland and, in the future, EGL/X11. Other backends
may opt for window specific vsyncsources as well at some point.
The idea is to, instead of using global vsync objects, expose a vsyncsource
from nsWindow and use it for refresh drivers. For the content process, move
VsyncChild to BrowserChild, so for each Browserchild there is only one
VsyncChild to which all refresh drivers connect.
IPC in managed either by PBrowser or PBackground. Right now, PBrowser is
only used on Wayland, as both PBrowser and the Wayland vsyncsource run
on the main thread. Other backends keep using the background thread for
now.
While at it, make it so that we constantly update the refresh rate. This
is necessary for Wayland, but also on other platforms variable refresh rates
are increasingly common. When using PVsync, limit updates to once in every
250ms in order to minimize overhead while still updating fast.
How to test:
- run the Wayland backend
- enable `widget.wayland_vsync.enabled`
- optionally: disable `privacy.reduceTimerPrecision`
- run `vsynctester.com` or `testufo.com`
Expected results:
Instead of fixed 60Hz, things should update at monitor refresh rate -
e.g. 144Hz
Original patch by Kenny Levinsen.
Differential Revision: https://phabricator.services.mozilla.com/D93173
To allow `requestAnimationFrame()` and similar things to run at monitor
speed if there is only a window-specific vsyncsource available.
This is the case for Wayland and, in the future, EGL/X11. Other backends
may opt for window specific vsyncsources as well at some point.
The idea is to, instead of using global vsync objects, expose a vsyncsource
from nsWindow and use it for refresh drivers. For the content process, move
VsyncChild to BrowserChild, so for each Browserchild there is only one
VsyncChild to which all refresh drivers connect.
IPC in managed either by PBrowser or PBackground. Right now, PBrowser is
only used on Wayland, as both PBrowser and the Wayland vsyncsource run
on the main thread. Other backends keep using the background thread for
now.
While at it, make it so that we constantly update the refresh rate. This
is necessary for Wayland, but also on other platforms variable refresh rates
are increasingly common. When using PVsync, limit updates to once in every
250ms in order to minimize overhead while still updating fast.
How to test:
- run the Wayland backend
- enable `widget.wayland_vsync.enabled`
- optionally: disable `privacy.reduceTimerPrecision`
- run `vsynctester.com` or `testufo.com`
Expected results:
Instead of fixed 60Hz, things should update at monitor refresh rate -
e.g. 144Hz
Original patch by Kenny Levinsen.
Differential Revision: https://phabricator.services.mozilla.com/D93173
TimeStamps in markers must now be streamed through `SpliceableJSONWriter::TimeProperty(name, timestamp)`.
This is consistent with all other JSON-writing functions being in `SpliceableJSONWriter` (and base class `JSONWriter`).
Depends on D97556
Differential Revision: https://phabricator.services.mozilla.com/D97557
Check `profiler_is_locked_on_current_thread()` before recording an IPC marker.
This removes the deadlock found in bug 1675406:
- SamplerThread: During sampling, some data is recorded into the profile buffer, which locks ProfileChunkedBuffer::mMutex, this triggers some chunk updates that are sent to ProfileBufferGlobalController, which attempts to lock its mutex.
- Main thread: An IPC with an update arrives, ProfileBufferGlobalController locks its mutex, then it sends an IPC out, this records a marker into ProfileChunkedBuffer, which attempts to lock its mMutex.
With this patch and bug 1671403, that last IPC will not record a marker anymore.
Differential Revision: https://phabricator.services.mozilla.com/D96971
* We add a new function to `mscom/Utils.h`: `DiagnosticNameForIID`. Its
purpose is to generate a friendly name for an interface, given an IID.
For special interfaces internal to COM, we add our own descriptive strings.
If the interface does not have a description, we simply convert the IID
to string format using GUIDToString.
* We modify `ProfilerMarkerChannelHook` to include the additional diagnostic
information for IIDs in its markers.
* Since each marker is now differentiated by IID, we remove the restriction
that we only use markers for the outermost COM call. In particular, this
assumption doesn't hold for asynchronous COM calls, so we would be losing
data in the case where an async call was pending while the main thread was
still making COM calls on other interfaces.
* There isn't really an effective way to distinguish between sync and
async calls at the channel hook layer. I'm thinking about how we could
perhaps modify `AsyncInvoker` to help mark these, but it's a bit messy.
I'm going to postpone that to future work.
* Other potential future work is expanding the number of interfaces for which
we have frendly names. I could see us annotating our various COM interfaces
in a way that we could automagically generate human-readable descriptions for
those interfaces.
Differential Revision: https://phabricator.services.mozilla.com/D97042
I realized that calling `mscom::IsProxy` is kind of redundant when we already
need to query for `ICallFactory`.
We still allow `aIsProxy` as an optional constructor argument, but if not
present then we go straight to `QueryInterface(IID_ICallFactory)`.
Differential Revision: https://phabricator.services.mozilla.com/D97047
We can now chaincreation of the decoder to the launch of the RDD process as needed and setting up the PRemoteDecoderManager
Differential Revision: https://phabricator.services.mozilla.com/D96365
PDMFactory::CreateDecoder is changed to return a MozPromise that will contain the MediaDataDecoder once created.
This will allow to later make RemoteDecoderManager fully asynchronous and no longer require an IPC sync call to start the RDD process.
We also modify the WebrtcMediaDataDecoderCodec to never create a decoder on the main thread, which could cause deadlocks under some circumstances.
Differential Revision: https://phabricator.services.mozilla.com/D96364
We can now chaincreation of the decoder to the launch of the RDD process as needed and setting up the PRemoteDecoderManager
Differential Revision: https://phabricator.services.mozilla.com/D96365
PDMFactory::CreateDecoder is changed to return a MozPromise that will contain the MediaDataDecoder once created.
This will allow to later make RemoteDecoderManager fully asynchronous and no longer require an IPC sync call to start the RDD process.
We also modify the WebrtcMediaDataDecoderCodec to never create a decoder on the main thread, which could cause deadlocks under some circumstances.
Differential Revision: https://phabricator.services.mozilla.com/D96364
The new infrastructure consists of a separate bridge between the content and the
parent process and a separate local storage database in the parent process.
The new infrastructure can be used for storing and sharing of private browsing
data across content processes.
This patch only creates necessary infrastructure, actual enabling of storing and
sharing of data across content processes will be done in a follow-up patch.
Differential Revision: https://phabricator.services.mozilla.com/D96562
When running as a "universal" build, use an x64 GMP child process if the CDM library is an x64 binary.
Use ifdefs extensively to reduce risk to Intel builds if the fix needs to be uplifted.
Requires a server-side balrog change to serve an Intel Widevine binary to ARM browser versions.
Differential Revision: https://phabricator.services.mozilla.com/D96288
Since python creates little-endian utf-16 consistently whether
cross-compiling from Linux or compiling natively on macOS, we could
write a small script that essentially replaces iconv. On the other hand,
we're also doing some manual preprocessing on the InfoPlist.strings.in
files, and we might as well use the preprocessor for that.
So, we augment the preprocessor to allow an explicit output encoding
other than utf-8, and use the preprocessor instead of `sed | iconv`.
Differential Revision: https://phabricator.services.mozilla.com/D96013
I need this for some changes I want to make to Win32 file pickers.
* We add an event-driven variant to `mscom::AsyncInvoker`. When the async call
invokes `ISynchronize::Signal`, we post an event to the specified event
target (or implicitly to the main thread).
* For this to work, the async call needs to temporarily retain a reference to
itself, otherwise the async call object is destroyed and the in-flight call
is cancelled. This reference is stored in an "outer runnable" which is
responsible for executing the inner completion runnable, and then dropping
the self-reference.
* We only run the completion runnable upon *successful* initiation of the async
call. If there was a failure, we return that code immediately to the caller.
Failures also clear the reference to the completion runnable.
* If we could not obtain an async interface and must run synchronously, then
we run the completion runnable immediately after a successful synchronous
invocation.
Differential Revision: https://phabricator.services.mozilla.com/D95808
Nika Layzell
Yaron Tausky
Andreas Farre
Rob Lemley
Tim Huang
Olli Pettay
Iulian Moraru
Alexandru Michis
Dorel Luca
Doug Thayer
Paul Bone
Butkovits Atila
Nicolas B. Pierron
Andi-Bogdan Postelnicu
Bob Owen
Calixte Denizet
Jed Davis
David Parks
Edgar Chen
Mitchell Hentges
Sean Feng
Christoph Kerschbaumer
Brad Werth
Brindusan Cristian
Csoregi Natalia
Ryan VanderMeulen
Eden Chuang
Andrew Osmond
Noemi Erli
Simon Giesecke
Tom Ritter
Cosmin Sabou
Florian Quèze
Niklas Gögge
smolnar
Chris Martin
Bogdan Tara
Jens Stutte
Mike Hommey
Jeff Muizelaar
Aaron Klotz
Gerald Squelart
M. Sirringhaus
Andreea Pavel
Eitan Isaacson
Deian Stefan
Masatoshi Kimura
Narcis Beleuzu
Kartik Gautam
Sylvestre Ledru
Markus Stange
Masayuki Nakano
Bryce Seager van Dyk
Karl Tomlinson
Tom Tung
Robert Mader
Haik Aftandilian
Thinker Li
Magnus Melin
Jean-Yves Avenard
Razvan Maries
Jan Varga
julianwels