Several widget contracts use different implementations in the parent and
content processes. Since the static registration system builds its hashtable
at compile time rather than runtime, it doesn't support different contract IDs
per process. It could make the decision at lookup time, but given how rarely
it's needed, I don't think it would be worth the complexity.
This patch updates the widget components that need different implementations
in the parent and content process to register separate contracts for each
implementation, and a third stub contract which forwards to the appropriate
implementation depending on which process it's used in. The implementation
entries restrict their usage to the process they are meant to be used in.
Differential Revision: https://phabricator.services.mozilla.com/D149436
Several widget contracts use different implementations in the parent and
content processes. Since the static registration system builds its hashtable
at compile time rather than runtime, it doesn't support different contract IDs
per process. It could make the decision at lookup time, but given how rarely
it's needed, I don't think it would be worth the complexity.
This patch updates the widget components that need different implementations
in the parent and content process to register separate contracts for each
implementation, and a third stub contract which forwards to the appropriate
implementation depending on which process it's used in. The implementation
entries restrict their usage to the process they are meant to be used in.
Differential Revision: https://phabricator.services.mozilla.com/D149436
Several widget contracts use different implementations in the parent and
content processes. Since the static registration system builds its hashtable
at compile time rather than runtime, it doesn't support different contract IDs
per process. It could make the decision at lookup time, but given how rarely
it's needed, I don't think it would be worth the complexity.
This patch updates the widget components that need different implementations
in the parent and content process to register separate contracts for each
implementation, and a third stub contract which forwards to the appropriate
implementation depending on which process it's used in. The implementation
entries restrict their usage to the process they are meant to be used in.
Differential Revision: https://phabricator.services.mozilla.com/D149436
It was for the sake of legacy extensions, which we don't care about, and
applies to `contract` manifest entries, which are being removed.
Differential Revision: https://phabricator.services.mozilla.com/D148190
This apparently hasn't been used for a while and has bit rotted, but it's
necessary for some migrations in later patches.
Differential Revision: https://phabricator.services.mozilla.com/D148180
This ensures that 0-delay timers are executed very quickly; without this, they
would rely on the timer thread waking up "naturally" as scheduled, but on some
platforms there could be significant delays (many milliseconds) before the
thread would actually wake up, compared to notifications that are handled
almost immediately.
Even though by specs, timers may be subject to being late, some users of
0-delay timers, in particular through JS' `setTimeout(code, 0)`, rely on the
code being executed as soon as possible (i.e., queued pretty much immediately
on the event loop).
Until now, this was almost guaranteed by the very frequent calls to
RemoveTimer, which always notified the timer thread and made it wake up very
quickly.
However the following patch is going to remove notifications from RemoveTimer,
so before that one lands we now need to ensure that 0-delay timer will still
be invoked at least as quickly as before.
Depends on D146030
Differential Revision: https://phabricator.services.mozilla.com/D149706
There is a code path that can make us not dispatch the `nsThreadShutdownAckEvent` at the end of `nsThread::ThreadFunc`. The only known and legitimate way to arrive here should be via StopWaitingAndLeakThread. We want to ensure that if we take this code path someone else already marked the shutdown context as complete.
Differential Revision: https://phabricator.services.mozilla.com/D148761
The last remaining things requiring unified builds in this directory are the
explicit specializations. As each class' methods are now confined to a single
file, these can now be moved to the appropriate .cpp files.
Differential Revision: https://phabricator.services.mozilla.com/D148303
These files exist only due to the history of how strings were previously
declared using macros, and aren't necessary anymore. The header files were not
removed, as they may be depended on from outside of the module. Cleaning up the
header situation is something which should probably happen in a follow-up.
Differential Revision: https://phabricator.services.mozilla.com/D148302
The remaining methods in ns[T]StringObsolete are all find+replace methods for
nsTSubstring. These were migrated in a similar way to the find methods, and
partially updated to avoid using methods from nsStringObsolete.cpp.
This change removes the ns[T]StringObsolete.cpp files completely, as they are
no longer necessary.
Differential Revision: https://phabricator.services.mozilla.com/D148301
The biggest set of APIs from ns[T]StringObsolete which are still heavily used
are the string searching APIs. It appears the intention was for these to be
replaced by the `FindInReadable` APIs, however that doesn't appear to have
happened.
In addition, the APIs have some quirks around their handling of mixed character
widths. These APIs generally supported both narrow strings and the native
string type, probably because char16_t string literals weren't available until
c++11. Finally they also used easy-to-confuse unlabeled boolean and integer
optional arguments to control behaviour.
These patches do the following major changes to the searching APIs:
1. The ASCII case-insensitive search method was split out as
LowerCaseFindASCII, rather than using a boolean. This should be less
error-prone and more explicit, and allows the method to continue to use
narrow string literals for all string types (as only ASCII is supported).
2. The other [R]Find methods were restricted to only support arguments with
matching character types. I considered adding a FindASCII method which would
use narrow string literals for both wide and narrow strings but it would've
been the same amount of work as changing all of the literals to unicode
literals.
This ends up being the bulk of the changes in the patch.
3. All find methods were re-implemented using std::basic_string_view's find
algorithm or stl algorithms to reduce code complexity, and avoid the need to
carry around the logic from nsStringObsolete.cpp.
4. The implementations were moved to nsTStringRepr.cpp.
5. An overload of Find was added to try to catch callers which previously
called `Find(..., false)` or `Find(..., true)` to set case-sensitivity, due
to booleans normally implicitly coercing to `index_type`. This should
probably be removed at some point, but may be useful during the transition.
Differential Revision: https://phabricator.services.mozilla.com/D148300
In addition to moving these methods to a more appropriate file, they were
simplified to make them easier to maintain in the future.
nsTStringRepr::Compare was extended to also work on char16_t strings, and the
case insensitive and other options were removed as they aren't necessary. This
required some changes to callers in the tree.
The EqualsIgnoreCase method was also simplified by using `std::string_view`.
Differential Revision: https://phabricator.services.mozilla.com/D148299
Due to the history of how nsString was implemented, many APIs ended up being
implemented in inappropriate files. This change moves simple definitions which
won't require any changes for each type to happen within that type's .cpp file.
This is necessary to eventually enable the directory to be built without
unified builds.
Differential Revision: https://phabricator.services.mozilla.com/D148298
This type was introduced in c++17, and can be used as a convenient standard
medium for passing around borrowed substring references. It can be implicitly
converted to from string literals and `const char_type*`, meaning that after
this change it can be used as a convenient catch-all type to replace seperate
overloads for `const self_type&`, `const char_type*` and `const
char_type(&)[N]`.
std::basic_string_view also provides standard implementations of some
algorithms which will be convenient for code cleanup in later parts of this
bug.
Differential Revision: https://phabricator.services.mozilla.com/D148297
This file only exists as a wrapper around nsTSubstring.cpp, with some methods
left in it due to how the string types were defined before they were turned
into templates.
Differential Revision: https://phabricator.services.mozilla.com/D148296
Otherwise the global ImplCycleCollectionUnlink for JS members are shadowed by mozilla::dom::ImplCycleCollectionUnlink and can't be used.
Bug 1756794 is to move all the impls to the single namespace to prevent this, but that requires verbose changes, and currently the only affected uses are from these macros.
Differential Revision: https://phabricator.services.mozilla.com/D147234
Previously this was optimized to trace only gray roots in collecting zones, but
there was a bug in that it also skipped clearing roots because this happens
before the start of GC when zones are selected for collection.
Instead, make sure we only perform this optimziation when marking.
Differential Revision: https://phabricator.services.mozilla.com/D146585
This patch won't actually build, because a few bits of code are used
for both nsIFactory::createInstance and static components, and static
components are not fixed until the next patch.
The first place is nsLoadGroupConstructor, which uses an nsIFactory
macro to create a static component constructor. (This could be worked
around by expanding the macro to the state before this patch.)
The other issue is that nsAppShellConstructor is used in an nsIFactory
on OSX, but as a static component on all other platforms. This could
be worked around by wrapping nsAppShellConstructor in an adaptor that
passes in the extra null argument to nsAppShellConstructor.
Differential Revision: https://phabricator.services.mozilla.com/D146456
nsIFactory is binary compatible with Windows COM's IClassFactory,
but nothing seems to depend on it. This patch removes the test
for compatibility, TestCOM, and removes the lockFactory
method that isn't otherwise needed.
Differential Revision: https://phabricator.services.mozilla.com/D146386
This allows us to replace a number of magic numbers in the
WebRequestError code with automatically generated constants which are
guaranteed to be kept up to date.
This build script is able to run early enough during the build step as
generated files which take a `.jinja` file as an argument are hard-coded
to be run during the pre-export phase for Android builds. As it is just
as simple python script with no other dependencies, this shouldn't
impact geckoview build performance even when using build artifacts.
Differential Revision: https://phabricator.services.mozilla.com/D146356
In order to get better shutdown hang reporting, we want to distinguish also the last phases, namely `XPCOMShutdownThreads`, `XPCOMShutdownMainThread` and `CCPostLastCycleCollection`.
This also makes `XPCOMShutdownNotified()` obsolete and we need to slightly re-arrange the watchdog function.
Differential Revision: https://phabricator.services.mozilla.com/D145433
The concept of a shutdown phase is meant to be a finite and named period of time where:
1. we can query if we are in or beyond a given phase
2. we may want to do a fast shutdown
3. we inform the terminator that we reached the next phase
4. if needed/wanted, we notify observers of the associated topic
5. we KillClearOnShutdown smart pointers associated with this phase
6. we do any further, phase-individual cleanup until the next phase starts
`AdvanceShutdownPhase(WithoutNotify)` now provides the functionality for 1. through 5. and must be the only place that calls `KillClearOnShutdown` in order to avoid misalignments.
In doing so, it becomes also the only caller of `MaybeFastShutdown`.
Please refer to bug 1768581 as working on this patch made us think if we should re-work the order inside AdvanceShutdownPhase.
Differential Revision: https://phabricator.services.mozilla.com/D145083
No reason these don't work on substrings.
Remove StripChars since it has an existing nsTSubstring version. Make
callers use rightly-typed characters for those.
Differential Revision: https://phabricator.services.mozilla.com/D145864
When the NS_AsyncCopy completes, there may still be outstanding
AsyncWait callbacks which have not been invoked yet, due to two
AsyncWait callbacks being registered each time Process() yields (one to
wait for the blocked stream, and the other with WAIT_CLOSURE_ONLY to
handle errors), and only one callback being needed to resume processing.
This change ensures that any outstanding AsyncWait callbacks are
cancelled, breaking references from the streams to the
nsAStreamCallback. Some streams (such as nsPipe and DataPipe) may also
leak if there are oustanding AsyncWait callbacks, due to the need to
keep the stream alive so it can be passed into the callback, which this
helps avoid.
Previously leaks were largely avoided due to the call to `Close()`
cancelling the callbacks for us, however not all callsites specify to
close the source/sink.
This should also help avoid an unnecessary dispatch after the copy
completes due to our AsyncWait callback being invoked when the
source/sink stream is closed.
Differential Revision: https://phabricator.services.mozilla.com/D146130
If we don't do this, we can encounter issues where we'll spuriously close the
stream when the last reference to the input stream is dropped while an
AsyncWait is still pending.
Differential Revision: https://phabricator.services.mozilla.com/D145672
As discovered by TSan, this member could be raced on in some edge-cases if
cloned pipe streams raced on multiple threads to be destroyed. This change
instead moves the `nsIPipe` implementation to be on a seperate type from
`nsPipe`, allowing `mOriginalInput` to no longer need to be tracked.
This technically has slightly different behaviour than the previous
implementation for JS code, as code keeping the `nsIPipe` alive will now also
be keeping the output stream reference alive directly, rather than only holding
the `nsIPipe`, meaning that `pipe.outputStream` can be read multiple times
independently without implicitly closing the underlying stream. Based on a
quick read of the few remaining uses of `nsIPipe` in JS code, I don't think
this will be an issue, and it may actually be more intuitive and consistent.
Differential Revision: https://phabricator.services.mozilla.com/D145362
Before this change, we could run into issues when an async stream
accepts new data and queues a runnable to notify the stream listener,
but before that stream listener's runnable is run, the target thread
reads data from the async stream, emptying it of any available data.
This would mean that the stream appears empty in
nsMultiplexInputStream::OnInputStreamReady, and the rest of the stream
is skipped.
This patch changes the logic in OnInputStreamReady to re-call AsyncWait
in those situations and avoid skipping over the empty stream, preventing
data loss.
This situation came up when running some HTTP tests under rr with the
socket process enabled, as the upload stream can both be read due to an
OnInputStreamReady callback and due to other calls in the HTTP
machinery, leading to this potential race. With the socket process
enabled, it is possible for the upload stream to be an async pipe, which
doesn't happen in the parent process due to stream normalization.
This change makes an assumption about the behaviour of streams
implementing `nsIAsyncInputStream` which I believe is correct right now,
and has been documented. I originally had other patches which modified
`Available()`'s definition to add an extra outparameter or added extra
methods, but this seemed much simpler and accurate based on my memory of
having read the Available() implementations for async streams in-tree.
A gtest was added for the failing situation using both nsPipe and DataPipe.
Differential Revision: https://phabricator.services.mozilla.com/D144451
As serializing IPCStream no longer requires a manager or FileDescriptor array,
the arguments are no longer necessary, and can be removed. The AutoIPCStream
helper can also be removed, as managed actors are no longer used for
serialization, so a delayed start callback is not necessary.
The delayed start parameter is also removed from nsIIPCSerializableInputStream
instances, but is still present as `aAllowLazy` on the toplevel serialization
methods.
Differential Revision: https://phabricator.services.mozilla.com/D141048
This type is no longer necessary, and has various issues due to behaving
incorrectly when used with async streams or streams which are not nsIPipe.
Differential Revision: https://phabricator.services.mozilla.com/D141045
Unfortunately, upload streams used by necko have various odd behaviours
and requirements which happened to be usually preserved by the previous
IPC serialization logic, but were not consistently preserved. This
includes requiring the stream to be synchronous (as some consumers such
as WebExtensions and DevTools appear to read it assuming Available() is
the stream length), seekable (as it needs to be rewound in various
places), and cloneable (as the stream information is often handed out to
other components).
In addition, the WebExtension WebRequest code makes assumptions about
the specific topology of the input stream for optimization purposes,
meaning that nsMultiplexInputStreams need to be preserved.
The way this was previously handled was by copying the entire payload
into a nsStorageStream as an async operation. This happened very
infrequently in out test suite, however, and had some issues. It could
lead to data loss if the stream was a nsMIMEInputStream (as the metadata
would be lost), and would destroy the topology required by WebRequest.
This patch changes the code to instead manually walk and replace streams
in the input stream's data structure, to efficiently copy only the
required data, preserve the invariants, and make the type seekable
before AsyncOpen continues. This helps keep the complexity of the
invariants HTTPChannel depends on out of generic input stream handling
code.
In addition, due to how early this happens, it replaces the need for
PartiallySeekableInputStream which will be removed a later part.
Differential Revision: https://phabricator.services.mozilla.com/D141044
This works only because the only implementation of nsIAsyncInputStreamLength
happened to only run on the current thread. Bug 1754004, changes this, and requires the reference to be threadsafe.
Differential Revision: https://phabricator.services.mozilla.com/D141037
This will improve the efficiency of serializing large data pipes, which in bad
cases can end up serializing very small amounts of data in individual pipes
over IPC, and acts as a compliment to the existing logic for limiting
serialized message sizes. It is also necessary for the changes in bug 1754004,
which require the ability to include FileDescriptor inline in the message,
which could blow out our FileDescriptor count limits if pipe creation was
unlimited.
In some tests, this change reduces the number of pipes required to serialize a
nsIInputStream from over 5000 to 1.
Differential Revision: https://phabricator.services.mozilla.com/D141036
This will help in bug 1754004 as in some cases we will want to clone a
DataPipe, which is non-cloneable, and without this change length information
would be lost.
In the future it might be worth making a more generic mechanism for efficiently
cloning wrapper input streams with a fallback rather than hard-coding this
interface.
Differential Revision: https://phabricator.services.mozilla.com/D141035
This operation is often performed by nsAStreamCopier when switching
between the source and sink streams, in order to enable or disable the
WAIT_CLOSURE_ONLY flag. Failing to reset the wait flags can lead to a
NS_AsyncCopy hanging until the source or sink are closed when is
alternating between waiting on input and output streams. This patch
relaxes the incorrect checks on various input streams.
Differential Revision: https://phabricator.services.mozilla.com/D141034
nsIPrintingPromptService comes from an era when the platform print code would
open the print settings dialog, which defaulted to the OS native dialogs.
Its purpose was to allow that dialog to be overridden by embedders to provide
their own interface for the user to select print settings. Nowadays the
platform print code does not open the dialogs. Instead apps like Firefox are
responsible for getting the print settings to pass to the platform code, and
the platform code provides a way to open the OS native print dialog if they
want to use that (nsIPrintDialogService). So nsIPrintingPromptService no longer
has any purpose, and just adds indirection and needless complexity.
Differential Revision: https://phabricator.services.mozilla.com/D146232
GCC has been unsupported to build for Windows since bug 1601690.
MSVC has been unsupported since bug 1512504.
We can thus assume that xptcstubs is always compiled with clang.
At the same time, because clang-trunk did an erroneous change to how
it handles __declspec(naked)*, use __attribute__((naked)) instead,
which is clang-only, and handled differently.
[*] https://github.com/llvm/llvm-project/issues/55362
Differential Revision: https://phabricator.services.mozilla.com/D145929
If we don't do this, we can encounter issues where we'll spuriously close the
stream when the last reference to the input stream is dropped while an
AsyncWait is still pending.
Differential Revision: https://phabricator.services.mozilla.com/D145672
As discovered by TSan, this member could be raced on in some edge-cases if
cloned pipe streams raced on multiple threads to be destroyed. This change
instead moves the `nsIPipe` implementation to be on a seperate type from
`nsPipe`, allowing `mOriginalInput` to no longer need to be tracked.
This technically has slightly different behaviour than the previous
implementation for JS code, as code keeping the `nsIPipe` alive will now also
be keeping the output stream reference alive directly, rather than only holding
the `nsIPipe`, meaning that `pipe.outputStream` can be read multiple times
independently without implicitly closing the underlying stream. Based on a
quick read of the few remaining uses of `nsIPipe` in JS code, I don't think
this will be an issue, and it may actually be more intuitive and consistent.
Differential Revision: https://phabricator.services.mozilla.com/D145362
Before this change, we could run into issues when an async stream
accepts new data and queues a runnable to notify the stream listener,
but before that stream listener's runnable is run, the target thread
reads data from the async stream, emptying it of any available data.
This would mean that the stream appears empty in
nsMultiplexInputStream::OnInputStreamReady, and the rest of the stream
is skipped.
This patch changes the logic in OnInputStreamReady to re-call AsyncWait
in those situations and avoid skipping over the empty stream, preventing
data loss.
This situation came up when running some HTTP tests under rr with the
socket process enabled, as the upload stream can both be read due to an
OnInputStreamReady callback and due to other calls in the HTTP
machinery, leading to this potential race. With the socket process
enabled, it is possible for the upload stream to be an async pipe, which
doesn't happen in the parent process due to stream normalization.
This change makes an assumption about the behaviour of streams
implementing `nsIAsyncInputStream` which I believe is correct right now,
and has been documented. I originally had other patches which modified
`Available()`'s definition to add an extra outparameter or added extra
methods, but this seemed much simpler and accurate based on my memory of
having read the Available() implementations for async streams in-tree.
A gtest was added for the failing situation using both nsPipe and DataPipe.
Differential Revision: https://phabricator.services.mozilla.com/D144451
As serializing IPCStream no longer requires a manager or FileDescriptor array,
the arguments are no longer necessary, and can be removed. The AutoIPCStream
helper can also be removed, as managed actors are no longer used for
serialization, so a delayed start callback is not necessary.
The delayed start parameter is also removed from nsIIPCSerializableInputStream
instances, but is still present as `aAllowLazy` on the toplevel serialization
methods.
Differential Revision: https://phabricator.services.mozilla.com/D141048
This type is no longer necessary, and has various issues due to behaving
incorrectly when used with async streams or streams which are not nsIPipe.
Differential Revision: https://phabricator.services.mozilla.com/D141045
Unfortunately, upload streams used by necko have various odd behaviours
and requirements which happened to be usually preserved by the previous
IPC serialization logic, but were not consistently preserved. This
includes requiring the stream to be synchronous (as some consumers such
as WebExtensions and DevTools appear to read it assuming Available() is
the stream length), seekable (as it needs to be rewound in various
places), and cloneable (as the stream information is often handed out to
other components).
In addition, the WebExtension WebRequest code makes assumptions about
the specific topology of the input stream for optimization purposes,
meaning that nsMultiplexInputStreams need to be preserved.
The way this was previously handled was by copying the entire payload
into a nsStorageStream as an async operation. This happened very
infrequently in out test suite, however, and had some issues. It could
lead to data loss if the stream was a nsMIMEInputStream (as the metadata
would be lost), and would destroy the topology required by WebRequest.
This patch changes the code to instead manually walk and replace streams
in the input stream's data structure, to efficiently copy only the
required data, preserve the invariants, and make the type seekable
before AsyncOpen continues. This helps keep the complexity of the
invariants HTTPChannel depends on out of generic input stream handling
code.
In addition, due to how early this happens, it replaces the need for
PartiallySeekableInputStream which will be removed a later part.
Differential Revision: https://phabricator.services.mozilla.com/D141044
Kris Maglione
criss
Marian-Vasile Laza
Jan Rio Krause
Ryan VanderMeulen
Gerald Squelart
Tooru Fujisawa
Mike Hommey
Molnar Sandor
Chris Martin
James Teh
Jens Stutte
Florian Quèze
Emilio Cobos Álvarez
Nika Layzell
alwu
Barret Rennie
Norisz Fay
Sylvestre Ledru
Steve Fink
Seweryn Pajor
Olli Pettay
Seweryn Pajor
Mozilla Releng Treescript
Narcis Beleuzu
Kagami Sascha Rosylight
Cathy Lu
Gijs Kruitbosch
Chris Peterson
Butkovits Atila
Iulian Moraru
Kershaw Chang
Jon Coppeard
Andrew McCreight
Randell Jesup
Autumn on Tape
Jonathan Watt
Mike Hommey
Noemi Erli
Bas Schouten