Previously if `Clone()` was called on a closed nsPipeInputStream, it could cause
crashes due to the already-closed nsPipeInputStream being added to mInputList,
violating internal nsPipe invariants. Skipping adding the stream to that list
should avoid this edge-case, as the pipe is already closed.
Differential Revision: https://phabricator.services.mozilla.com/D101807
This patch introduces a new SeekableStreamWrapper class which handles adapting
nsIInputStreams which support being cheaply cloned using nsICloneableInputStream
into seekable input streams by operating on a clone of the original stream, and
re-cloning that stream when seeking backwards.
This wrapper is generally intended to be used with nsPipeInputStream as that
type supports both a fairly cheap clone operation, and keeping a large internal
buffer which is fairly cheap to seek using this method, but should also work
with other types such as RemoteLazyInputStream or nsStringStream.
An alternate strategy was considered where nsPipe was given internal support for
a mSeekable flag to be set on creation. This flag would then have a similar
effect, except with additional optimizations due to being visible within the
implementation of the nsPipe, rather than relying on an unadvanced
nsPipeInputStream to keep the buffer alive.
I ended up choosing this approach instead for a few reasons:
* The seekable adapter can be applied to an already-created nsPipeInputStream,
such as one received from IPC. With the nsPipe approach, making an IPC stream
seekable either requires telling IPCStreamDestination to use a seekable pipe
ahead of time, or performing a NS_AsyncCopy from the IPC-provided pipe into a
different seekable pipe, which is likely wasted effort and would prevent
optimizations such as RemoteLazyInputStream and DelayedStart streams.
* The adapter can support other features of the underlying stream, such as
nsIInputStreamLength, without resorting to adding additional adapter layers
on top of the returned nsPipe.
* The performance is unlikely to be substantially different in the most common
case, which is using Seek(NS_SEEK_SET, 0) to return to the beginning of the
stream.
* Less additional complexity is added to the already-complicated internals of
nsPipe, and instead it is kept in a separate wrapper stream, which is easier
to review.
Using nsStorageStream, as is used by EnsureUploadStreamIsCloneable, was also
considered, but was rejected as it has similar problems to the seekable nsPipe
approach and also doesn't implement nsIAsyncStream, meaning that one must wait
for the NS_AsyncCopy to be completed before reading the stream.
It may actually be possible to replace the existing uses of nsStorageStream with
a wrapped nsPipe in the future, but that is left as follow-up material, and may
have memory overhead implications due to nsPipe not resizing the final segment,
unlike nsStorageStream.
Differential Revision: https://phabricator.services.mozilla.com/D101805
One thing we have to do when tracaing is udpate context information (e.g. edge name) if the tracer is a kind that requires it. It's simpler and more efficient to give all tracers this context and perform an unconditional write to the stack.
Mostly we can get away without saving/restoring context information too. This adds AutoClearTracingContext for the one place we need to do this because of nested use of the same tracer while tracing something else.
Differential Revision: https://phabricator.services.mozilla.com/D103500
Bug 608915 switched nsString::AppendFloat to double-conversion, while
handling trailing zero removal on its own. This can be made more
effectively when doing so in double-conversion itself, support for which
was merged upstream in https://github.com/google/double-conversion/pull/149.
This makes the used_exponential_notation outparam unnecessary.
Differential Revision: https://phabricator.services.mozilla.com/D102698
nsBaseHashtable now supports non-default-constructible DataType and
UserDataType, however not all methods can be instantiated. All methods which
can't be instantiated with non-default-constructible DataType or UserDataType
are now described as such in method definitions.
The public API of PLDHashTable and nsBaseHashtable/nsDataHashtable was changed:
- A new method PLDHashTable::WithEntryHandle has been added. It allows to use a
custom function for entry initialization (instead of the global hook).
- A new method nsBaseHashtable::MaybeGet has been added.
- A new overload nsBaseHashtable::Remove has been added.
- The nsDataHashtable::GetAndRemove method has been pulled up to
nsBaseHashtable.
In addition, the following implementation details have changed:
PLDHashTable:
- The code from the Add method has been split into MakeEntryHandle and a helper
object called EntryHandle. The Add method is now implemented on top of that.
nsTHashtable:
- A new (non-public) API for WithEntryHandle has been added.
- The InitEntry hook is no longer used. Instead of using the hook, PutEntry
methods now use nsTHashtable::WithEntryHandle instead of PLDHashTable::Add.
This change allows to do custom initialization in derived classes.
nsBaseHashtable:
- A new (non-public) API for WithEntryHandle has been added.
- Put methods no longer use nsTHashtable::PutEntry, they now use the new method
nsBaseHashtable::WithEntryHandle.
Differential Revision: https://phabricator.services.mozilla.com/D99428
nsBaseHashtable now supports non-default-constructible DataType and
UserDataType, however not all methods can be instantiated. All methods which
can't be instantiated with non-default-constructible DataType or UserDataType
are now described as such in method definitions.
The public API of PLDHashTable and nsBaseHashtable/nsDataHashtable was changed:
- A new method PLDHashTable::WithEntryHandle has been added. It allows to use a
custom function for entry initialization (instead of the global hook).
- A new method nsBaseHashtable::MaybeGet has been added.
- A new overload nsBaseHashtable::Remove has been added.
- The nsDataHashtable::GetAndRemove method has been pulled up to
nsBaseHashtable.
In addition, the following implementation details have changed:
PLDHashTable:
- The code from the Add method has been split into MakeEntryHandle and a helper
object called EntryHandle. The Add method is now implemented on top of that.
nsTHashtable:
- A new (non-public) API for WithEntryHandle has been added.
- The InitEntry hook is no longer used. Instead of using the hook, PutEntry
methods now use nsTHashtable::WithEntryHandle instead of PLDHashTable::Add.
This change allows to do custom initialization in derived classes.
nsBaseHashtable:
- A new (non-public) API for WithEntryHandle has been added.
- Put methods no longer use nsTHashtable::PutEntry, they now use the new method
nsBaseHashtable::WithEntryHandle.
Differential Revision: https://phabricator.services.mozilla.com/D99428
This patch does several things:
- make the counter type int64_t like the work budget parameter (the original purpose of this bug)
- simplify implementation by using a Variant to discriminate between different kinds of budget
- remove the global initialization
- remove makeUnlimited() (and replace uses with assignment from SliceBudget::unlimited())
- add convenience methods to get the original budget parameters
- add basic API tests
The use of Variant had the consequence that we now have to pass SliceBudget by reference now to make the linter happy.
Differential Revision: https://phabricator.services.mozilla.com/D103318
Bug 608915 switched nsString::AppendFloat to double-conversion, while
handling trailing zero removal on its own. This can be made more
effectively when doing so in double-conversion itself, support for which
was merged upstream in https://github.com/google/double-conversion/pull/149.
This makes the used_exponential_notation outparam unnecessary.
Differential Revision: https://phabricator.services.mozilla.com/D102698
For simplicity, this implements just on in `NO_TASKS` (the default) or
on in `ALL_TASKS` (opt-in). This disables all category registrations
when in background task mode; we'll selectively re-enable things as
appropriate.
The flag constants were chosen to smoothly extend to a (16-)bit set in
the future, should we want to add a `JUST_TASKS("task", "other-task")`
option in the future.
This also adds ython tests for gen_static_components.py exercising
categories, simply 'cuz it's easiest to see what this adds in such
tests. Functional tests will follow in patches that actually
implement the new background tasks functionality.
Differential Revision: https://phabricator.services.mozilla.com/D96654
This allows to filter chrome manifest registration by the current
background task(s, in the future). Filtration behaves just like
filtering by "application":
* filter with `backgroundtask=` means disable for all background
tasks, since no background task will match ""
* filter with `backgroundtask!=` means enable for all background task,
since every background task will not match ""
Differential Revision: https://phabricator.services.mozilla.com/D96482
Previously if `Clone()` was called on a closed nsPipeInputStream, it could cause
crashes due to the already-closed nsPipeInputStream being added to mInputList,
violating internal nsPipe invariants. Skipping adding the stream to that list
should avoid this edge-case, as the pipe is already closed.
Differential Revision: https://phabricator.services.mozilla.com/D101807
This patch introduces a new SeekableStreamWrapper class which handles adapting
nsIInputStreams which support being cheaply cloned using nsICloneableInputStream
into seekable input streams by operating on a clone of the original stream, and
re-cloning that stream when seeking backwards.
This wrapper is generally intended to be used with nsPipeInputStream as that
type supports both a fairly cheap clone operation, and keeping a large internal
buffer which is fairly cheap to seek using this method, but should also work
with other types such as RemoteLazyInputStream or nsStringStream.
An alternate strategy was considered where nsPipe was given internal support for
a mSeekable flag to be set on creation. This flag would then have a similar
effect, except with additional optimizations due to being visible within the
implementation of the nsPipe, rather than relying on an unadvanced
nsPipeInputStream to keep the buffer alive.
I ended up choosing this approach instead for a few reasons:
* The seekable adapter can be applied to an already-created nsPipeInputStream,
such as one received from IPC. With the nsPipe approach, making an IPC stream
seekable either requires telling IPCStreamDestination to use a seekable pipe
ahead of time, or performing a NS_AsyncCopy from the IPC-provided pipe into a
different seekable pipe, which is likely wasted effort and would prevent
optimizations such as RemoteLazyInputStream and DelayedStart streams.
* The adapter can support other features of the underlying stream, such as
nsIInputStreamLength, without resorting to adding additional adapter layers
on top of the returned nsPipe.
* The performance is unlikely to be substantially different in the most common
case, which is using Seek(NS_SEEK_SET, 0) to return to the beginning of the
stream.
* Less additional complexity is added to the already-complicated internals of
nsPipe, and instead it is kept in a separate wrapper stream, which is easier
to review.
Using nsStorageStream, as is used by EnsureUploadStreamIsCloneable, was also
considered, but was rejected as it has similar problems to the seekable nsPipe
approach and also doesn't implement nsIAsyncStream, meaning that one must wait
for the NS_AsyncCopy to be completed before reading the stream.
It may actually be possible to replace the existing uses of nsStorageStream with
a wrapped nsPipe in the future, but that is left as follow-up material, and may
have memory overhead implications due to nsPipe not resizing the final segment,
unlike nsStorageStream.
Differential Revision: https://phabricator.services.mozilla.com/D101805
Otherwise autoplay blocking until-in-foreground breaks with the other
patch in this bug, because it unblocks media playback once a browsing
context is active for the first time.
Differential Revision: https://phabricator.services.mozilla.com/D42329
These lines are parsed by the `htmlparser` and are expected to be on a single
line. The `black` reformat has moved some of these definitions to multiple lines
due to line length. This commit moves all declarations back to a single line and
adds `fmt: {off,on}` statements so they will be ignored in future reformats.
Differential Revision: https://phabricator.services.mozilla.com/D102626
Otherwise autoplay blocking until-in-foreground breaks with the other
patch in this bug, because it unblocks media playback once a browsing
context is active for the first time.
Differential Revision: https://phabricator.services.mozilla.com/D42329
This commit makes `gXPCOMThreadsShutdown` atomic. I've deliberated on this one for a while because I was mostly interested in how timer threads may be trying to init during shutdown, but these aren't the only places where we are making accesses into `gXPCOMThreadsShutdown` so it should be made atomic regardless.
Differential Revision: https://phabricator.services.mozilla.com/D102486
Note that there's still a little plugin related code in
widget/ and gfx/ etc after this. That can be removed
once we remove plugin support from dom/ etc.
The removal from layout/ should be pretty complete though.
Differential Revision: https://phabricator.services.mozilla.com/D102140
Otherwise autoplay blocking until-in-foreground breaks with the other
patch in this bug, because it unblocks media playback once a browsing
context is active for the first time.
Differential Revision: https://phabricator.services.mozilla.com/D42329
Currently, printf_stderr doesn't show up when running with ./mach run.
This is because we run with -attach-console and that redirects stderr
to a different file descriptor using freopen in UseParentConsole.
The change from just using stderr directly happened in bug 340443 and was done
to avoid some linking issues. That problem doesn't seem to apply anymore so you'd
expect we'd be able to go back to the straightforward implemention that works even
if stderr has been redirected. Unforunately, Windows takes not buffering
stderr very seriously and fprintf will write out the results character
by character. This can cause log output lines to be intermixed which
breaks log parsing in CI. We keep using fdopen to create a new FILE*
that's buffered but instead of hard coding fd 2, we get the actual fd
that corresponds to stderr using fileno.
The mozglue implementation was cargo culted from xpcom, so we update it
as well.
Differential Revision: https://phabricator.services.mozilla.com/D98550
Jon Bauman
Nika Layzell
Gijs Kruitbosch
Cameron Kaiser
Chris H-C
nirmay
Jon Coppeard
Mike Hommey
Jan Varga
Brindusan Cristian
Masayuki Nakano
Caroline Cullen
Csoregi Natalia
Andrew McCreight
Florian Quèze
Nick Alexander
Doug Thayer
Butkovits Atila
Mozilla Releng Treescript
Tom Schuster
Markus Stange
Masatoshi Kimura
Emilio Cobos Álvarez
Connor Sheehan
Cosmin Sabou
Kris Wright
Mats Palmgren
Dorel Luca
Bas Schouten
Simon Giesecke
Jeff Muizelaar
Mitchell Hentges