First, it should be called "Lookup" rather than "Get" because it returns
DataType (rather than UserDataType), but that would still be confusing,
since as opposed to other Lookup* methods, it does not return a DataType&
(and obviously, it can't). So "Extract" seems to be a better name, cf.
mozilla::Maybe::extract.
Differential Revision: https://phabricator.services.mozilla.com/D105471
It should be called "Get" rather than "Lookup" because it returns
UserDataType. "Add" is called "Insert" in the other methods.
Differential Revision: https://phabricator.services.mozilla.com/D105470
These services had their name added to components.conf:
* GfxInfo
* ThirdPartyUtil
* History
* HttpActivityDistributor
* UUIDGenerator
* ServiceWorkerManager
* PermissionManager
These services were added to componenets.conf under a different name:
* DirectoryService => Directory
* IOService => IO
* StringBundleService => StringBundle
* CacheStorageService => CacheStorage
* StreamTransportService => StreamTransport
* SocketTransportService => SocketTransport
These services weren't migrated to components.conf because only Rust
code uses them:
* RemoteAgent
* XULRuntime
* PrefService
These services weren't migrated to components.conf because they're unused:
* ToolkitChromeRegistry (used as ChromeRegistry)
* XULChromeRegistry (used as ChromeRegistry)
* Bits (completely unused)
These services were already available in components.conf but are still
used by rust code:
* URIFixup
These services weren't migrated because they will be handled in
subsequent patchsets:
* ObserverService
For the record, the following Services are being used by Rust code
and must remain until a Rust version of Components.h is written:
* RemoteAgent
* XULRuntime
* PrefService
* URIFixup
* ObserverService
* DirectoryService
* ThirdPartyUtil
Also the cocoa GfxInfo service was changed to use components.conf instead
of registering it at runtime, as all the other widgets were already doing
it this way.
Differential Revision: https://phabricator.services.mozilla.com/D105521
No code changes.
Build issues were found by renaming `MOZ_GECKO_PROFILER` to something else in toolkit/moz.configure, in both unified and non-unified builds, on all supported platforms.
Also updated some profiler-related comments.
Differential Revision: https://phabricator.services.mozilla.com/D105375
This macro was quite misguided, too. If evaluating _e raised an exception, then
the expression value of the block would be an uninitialized value. Super unsafe.
It's a good thing that we don't expect "retain" to ever throw.
Differential Revision: https://phabricator.services.mozilla.com/D104954
Instead of snprintf.
Because some standalone code uses those functions directly or indirectly,
and PrintfTarget lives in mozglue, they now need to depend on mozglue
instead of mfbt. Except logalloc/replay, which cherry-picks what it
uses.
Differential Revision: https://phabricator.services.mozilla.com/D103730
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
Instead of snprintf.
Because some standalone code uses those functions directly or indirectly,
and PrintfTarget lives in mozglue, they now need to depend on mozglue
instead of mfbt. Except logalloc/replay, which cherry-picks what it
uses.
Differential Revision: https://phabricator.services.mozilla.com/D103730
Actually, there's not so much we can improve right now, in the sense
that:
* We need the ::-moz-page-content pseudo-element to be able to set
`display` on the page, since that's a style rule rather than a @page
rule. We could get away without it.
* Keeping the current code-path (slightly cleaned up) is less code, for
now at least. We can have a separate code-path or what not that
actually performs the @page rule selector-matching and what not if
needed when we get to named pages or other page selectors. Selectors
like :first should be pretty trivial to implement, actually.
We make some paged mode anon boxes non-inheriting anon boxes. This
allows us to share the styles and is generally nicer. They don't need to
inherit from anywhere.
We could remove the origin handling and don't look at UA rules or what
not, but it seems pretty harmless to do that.
We also fix the name of the pseudo-elements to match the capitalization.
Differential Revision: https://phabricator.services.mozilla.com/D104772
Actually, there's not so much we can improve right now, in the sense
that:
* We need the ::-moz-page-content pseudo-element to be able to set
`display` on the page, since that's a style rule rather than a @page
rule. We could get away without it.
* Keeping the current code-path (slightly cleaned up) is less code, for
now at least. We can have a separate code-path or what not that
actually performs the @page rule selector-matching and what not if
needed when we get to named pages or other page selectors. Selectors
like :first should be pretty trivial to implement, actually.
We make some paged mode anon boxes non-inheriting anon boxes. This
allows us to share the styles and is generally nicer. They don't need to
inherit from anywhere.
We could remove the origin handling and don't look at UA rules or what
not, but it seems pretty harmless to do that.
We also fix the name of the pseudo-elements to match the capitalization.
Differential Revision: https://phabricator.services.mozilla.com/D104772
We're adding support for ArrayBuffers larger than 4 GB to the JS engine (on 64-bit
platforms).
ReadArrayBuffer uses uint32_t values in a number of places. This patch changes them
to uint64_t where necessary. Values related to the temporary buffer stay uint32_t because
that buffer is <= 4096 bytes.
Differential Revision: https://phabricator.services.mozilla.com/D103759
Implements the missing handle functions (OrInsertWith, OrUpdateWith), and harmonizes functions
to return a reference to the data.
Adds unit tests.
Differential Revision: https://phabricator.services.mozilla.com/D99764
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
Noemi Erli
Mozilla Releng Treescript
Simon Giesecke
Markus Stange
Marco Castelluccio
Alexis Beingessner
Bas Schouten
Gerald Squelart
Andreea Pavel
Mike Hommey
smolnar
Mihai Alexandru Michis
Emilio Cobos Álvarez
Butkovits Atila
Jan de Mooij
Sean Feng
Kershaw Chang
Nick Alexander
Nika Layzell