Before this set of patches, the decision of exposing the stream as a pipe was
centralized in IPCStreamUtils, based on the total expectation size of the IPC
message. This triggers issues when multiplex inputStreams contain something
that cannot be sent as a pipe (IPCBlobInputStream, for instance), or something
that it's better to do not set as a pipe (nsFileInputStream), together with
memory streams (nsStringInputStream), which could make the IPC message greater
then what accepted (1mb).
These patches move the "pipe vs non-pipe" choice into the single inputStream
implementation.
AsyncWaitRunnable holds a strong reference to its stream, and
NonBlockingAsyncInputStream holds a strong reference to the
runnable. The cycle gets broken in the RunAsyncWaitCallback() method
of the stream, but if the runnable is cancelled then we leak them
both. This patch fixes that by clearing the pointer to the stream when
the runnable is cancelled, breaking the cycle.
Differential Revision: https://phabricator.services.mozilla.com/D16248
--HG--
extra : moz-landing-system : lando
AsyncWaitRunnable holds a strong reference to its stream, and
NonBlockingAsyncInputStream holds a strong reference to the
runnable. The cycle gets broken in the RunAsyncWaitCallback() method
of the stream, but if the runnable is cancelled then we leak them
both. This patch fixes that by clearing the pointer to the stream when
the runnable is cancelled, breaking the cycle.
Differential Revision: https://phabricator.services.mozilla.com/D16248
--HG--
extra : moz-landing-system : lando
This is a best effort attempt at ensuring that the adverse impact of
reformatting the entire tree over the comments would be minimal. I've used a
combination of strategies including disabling of formatting, some manual
formatting and some changes to formatting to work around some clang-format
limitations.
Differential Revision: https://phabricator.services.mozilla.com/D13371
--HG--
extra : moz-landing-system : lando
* Changes the format of the blocklist from a list of characters to a list of
character ranges. Binary search still works, and it is easier to include
large ranges of characters in the blocklist.
* Moves logic for handling the blocklist to IDNBlocklistUtils.h/.cpp
* Changes NS_EscapeURL to take a function that determines if a character
is blocked. This way the type of the array doesn't matter.
Differential Revision: https://phabricator.services.mozilla.com/D12210
--HG--
extra : moz-landing-system : lando
In the current code there are 3 main issues:
1. nsFileStream is not really thread-safe. There is nothing to protect the
internal members and we see crashes.
2. nsPipeInputStream doesn't implement ::Seek() method and that caused issues
in devtools when a nsHttpChannel sends POST data using a pipe. In order to fix
this, bug 1494176 added a check in nsHttpChannel: if the stream doesn't
implement ::Seek(), let's clone it. This was an hack around nsPipeInputStream,
and it's bad.
3. When nsHttpChannel sends POST data using a file stream, nsFileStream does
I/O on main-thread because of the issue 2. Plus, ::Seek() is called on the
main-thread causing issue 1.
Note that nsPipeInputStream implements only ::Tell(), of the nsISeekableStream
methods. It doesn't implement ::Seek() and it doesn't implement ::SetEOF().
With this patch I want to fix point 2 and point 3 (and consequentially issue 1
- but we need a separate fix for it - follow up). The patch does:
1. it splits nsISeekableStream in 2 interfaces: nsITellableStream and
nsISeekableStream.
2. nsPipeInputStream implements only nsITellableStream. Doing this, we don't
need the ::Seek() check for point 2 in nsHttpChannel: a simple QI check is
enough.
3. Because we don't call ::Seek() in nsHttpChannel, nsFileStream doesn't do I/O
on the main-thread, and we don't crash doing so.
The sandbox blocks GetTempFileName's prior response, causing the system to end up searching a number of (inaccessible) folders to use as a replacement for the temp folder. This patch provides a path to a new folder on the command line for the plugin process. This new temp folder, specific to this plugin process instance, is then communicated to the system via the TEMP/TMP environment variables. This is similar to what is done for the content process but avoids nsDirectoryService, which doesn't exist in plugin processes.
Differential Revision: https://phabricator.services.mozilla.com/D7532
--HG--
extra : moz-landing-system : lando
The sandbox blocks GetTempFileName's prior response, causing the system to end up searching a number of (inaccessible) folders to use as a replacement for the temp folder. This patch provides a path to a new folder on the command line for the plugin process. This new temp folder, specific to this plugin process instance, is then communicated to the system via the TEMP/TMP environment variables. This is similar to what is done for the content process but avoids nsDirectoryService, which doesn't exist in plugin processes.
Differential Revision: https://phabricator.services.mozilla.com/D7532
--HG--
extra : moz-landing-system : lando
The sandbox blocks GetTempFileName's prior response, causing the system to end up searching a number of (inaccessible) folders to use as a replacement for the temp folder. This patch provides a path to a new folder on the command line for the plugin process. This new temp folder, specific to this plugin process instance, is then communicated to the system via the TEMP/TMP environment variables. This is similar to what is done for the content process but avoids nsDirectoryService, which doesn't exist in plugin processes.
Differential Revision: https://phabricator.services.mozilla.com/D7532
--HG--
extra : moz-landing-system : lando
This removes the rarely used and somewhat odd
`iterator& BeginWriting/EndWriting(iterator&)` functions that take an iterator
as an in/out param and then return it.
--HG--
extra : rebase_source : 92066f996595e9b7df9642813c08592cee47c630
This switches over the few remaining usages of the deprecated
BeginWriting/EndWriting(iterator&) functions to the more standard
BeginWriting/EndWriting() functions.
--HG--
extra : rebase_source : 3c54621d4921eb45157ec4edce0b693bdd7f02d5
Also rewrote some code around the actual problem to be more obviously correct
and comprehensible.
MozReview-Commit-ID: FF2hSjQ4U1x
Differential Revision: https://phabricator.services.mozilla.com/D5154
--HG--
extra : moz-landing-system : lando
There are surprisingly many of them.
(Plus a couple of unnecessary checks after `new` calls that were nearby.)
--HG--
extra : rebase_source : 47b6d5d7c5c99b1b50b396daf7a3b67abfd74fc1
This allows JS callers to automatically get the correct types during
interation, without having to explicitly specify them.
Differential Revision: https://phabricator.services.mozilla.com/D3728
--HG--
extra : rebase_source : b708f382d8ea571d199c669bfed5b5a7ca9ffac4
extra : histedit_source : 7df6feb82088c8a5ca45dc28fe4d2b852c177fee
This patch adds simple stubs to convert between the nsISimpleEnumerator
iteration protocol and the JS iteration protocol.
Each iterable object is required to have an @@iterator method which returns an
object implementing the iterator protocol. The later objects, by convention,
also have such a method which returns the object itself.
This patch adds both a @@iterator() and entries() methods to
nsISimpleEnumerator. The former returns an iterator which returns plain
nsISupports objects. The latter accepts an IID and queries each element to
that IID before returning it. If any element fails to query, the error is
propagated to the caller.
Differential Revision: https://phabricator.services.mozilla.com/D3727
--HG--
extra : rebase_source : 340eb43a1c5e6d7ae69fa8ee486d66d31d079b14
extra : histedit_source : f3efc6c265851a563968ee410e4626e0540f55c0
The nsISimpleEnumerator contract specifies that GetNext() returns
NS_ERROR_FAILURE when iteration is complete. Several implementations, however,
either return NS_OK and a null result, or return some other error code, when
iteration is complete.
Since my initial implementation of the JS iteration stubs rely on the
contract-defined behavior of GetNext(), these need to be fixed before it can
land.
Differential Revision: https://phabricator.services.mozilla.com/D3726
--HG--
extra : rebase_source : aab0395df52e18ccff5b0a2489a983013bf484b1
extra : histedit_source : a5644f0a88799b4463af9dd01dfec33b373b1f58
In order to allow JS callers to use nsISimpleEnumerator instances with the JS
iteration protocol, we'll need to additional methods to every instance. Since
we currently have a large number of unrelated implementations, it would be
best if they could share the same implementation for the JS portion of the
protocol.
This patch adds a stub nsSimpleEnumerator base class, and updates all existing
implementations to inherit from it. A follow-up will add a new base interface
to this class, and implement the additional functionality required for JS
iteration.
Differential Revision: https://phabricator.services.mozilla.com/D3725
--HG--
extra : rebase_source : ad66d7b266856d5a750c772e4710679fab9434b1
extra : histedit_source : a83ebffbf2f0b191ba7de9007f73def6b9a955b8
Much like the component manager, many of the strings that we use for category
manager entries are statically allocated. There's no need to duplicate these
strings.
This patch changes the category manager APIs to take nsACStrings rather than
raw pointers, and to pass literal nsCStrings when we know we have a literal
string to begin with. When adding the category entry, it then skips making
copies of any strings with the LITERAL flag.
MozReview-Commit-ID: EJEcYSdNMWs
***
amend-catman
--HG--
extra : source : aa9a8f18e98f930a3d8359565eef02f3f6efc5f9
extra : absorb_source : 81a22ab26ee8017ac43321ff2c987d8096182d37
Much like the component manager, many of the strings that we use for category
manager entries are statically allocated. There's no need to duplicate these
strings.
This patch changes the category manager APIs to take nsACStrings rather than
raw pointers, and to pass literal nsCStrings when we know we have a literal
string to begin with. When adding the category entry, it then skips making
copies of any strings with the LITERAL flag.
MozReview-Commit-ID: EJEcYSdNMWs
***
amend-catman
--HG--
extra : rebase_source : 4f70e7b296ecf3b52a4892c92155c7c163d424d2
This patch is an automatic replacement of s/NS_NOTREACHED/MOZ_ASSERT_UNREACHABLE/. Reindenting long lines and whitespace fixups follow in patch 6b.
MozReview-Commit-ID: 5UQVHElSpCr
--HG--
extra : rebase_source : 4c1b2fc32b269342f07639266b64941e2270e9c4
extra : source : 907543f6eae716f23a6de52b1ffb1c82908d158a
This change makes nsEscape::T_EscapeURL not escape spaces when passed esc_OnlyNonASCII.
This fixes a web-compat issue for URLs such as "javascript: alert('hello');" and the fact that data: URIs with spaces around MIME type are rejected.
MozReview-Commit-ID: 91Qw9foW6Y3
--HG--
extra : rebase_source : 2da1b5f305ca2abcce2f9988cd6a5cbc12635c61
This change makes nsEscape::T_EscapeURL not escape spaces when passed esc_OnlyNonASCII.
This fixes a web-compat issue for URLs such as "javascript: alert('hello');" and the fact that data: URIs with spaces around MIME type are rejected.
MozReview-Commit-ID: B78AacLxGBp
--HG--
extra : rebase_source : fcef25fab58f7da1732725054ae684588f2e0e89
This was done automatically replacing:
s/mozilla::Move/std::move/
s/ Move(/ std::move(/
s/(Move(/(std::move(/
Removing the 'using mozilla::Move;' lines.
And then with a few manual fixups, see the bug for the split series..
MozReview-Commit-ID: Jxze3adipUh
Any more specific work that is happening in these methods will have its own
specific category labeling in that specific code. The instances touched in this
patch are more on the outside and don't really know what kind of code is going
to be running inside.
MozReview-Commit-ID: 47NO1DZzkdH
--HG--
extra : rebase_source : 344c380ddaaf42a1fd820a26b762c61ee9e2d524
Any more specific work that is happening in these methods will have its own
specific category labeling in that specific code. The instances touched in this
patch are more on the outside and don't really know what kind of code is going
to be running inside.
MozReview-Commit-ID: 47NO1DZzkdH
--HG--
extra : rebase_source : f807c14bf6a592e0c651e15b63d1e7d63e4b0159
All of our GetDirectoryEntries implementations return a
nsIDirectoryEnumerator, and a lot of relies on this, and explicitly QIs to it.
That gets a bit ugly, and in JS code, a bit expensive. We should just return a
directory enumerator directly if that's part of the API contract.
MozReview-Commit-ID: IUeEB1Ih1Wu
--HG--
extra : rebase_source : 6fffb2d4b0f83db1fd270423a195379acef0dfe4
For reasons unknown, if you give MSVC:
// Foo.h
struct Foo
{
...
};
extern const Foo gFoo;
// Foo.cpp, which necessarily includes Foo.h.
extern constexpr Foo gFoo = {
};
MSVC will create a static initializer for gFoo and place it in the
read/write data section, rather than the read-only data section.
Removing the `extern const` declaration seems to be enough to make this
problem go away. We need to adjust the declaration of other variables
to compensate for the non-visibility of gFoo in the header file.
Each nsStaticAtomSetup contains a pointer to a static atom, and also a pointer
to the canonical pointer to that static atom. Which is pretty weird! The
notable thing thing about it is that these structs are in an array, and that
gives us the only way to iterate over all static atoms in a single class, for
registration and lookups.
But thanks to various other recent changes to the implementation of static
atoms, we can now put the static atoms themselves into an array, which can be
iterated over. So this patch does that. With that done, nsStaticAtomSetup is no
longer necessary.
According to the `size` utility, on Linux64 this reduces the size of libxul.so
by the following amounts:
> text: 62008 bytes
> data: 20992 bytes
> bss: 21040 bytes
> total: 104040 bytes
- The bss reduction is one word per atom, because the canonical static atom
pointers (e.g. nsGkAtoms::foo) have moved from .bss to .data, because they're
now initialized at compile time instead of runtime.
- The data reduction is one word per atom, because we remove two words per atom
for the nsStaticAtomSetup removal, but gain one word per atom from the
previous bullet point.
- I'm not sure about the text reduction. It's three words per atom. Maybe
because there is one less relocation per atom?
Other notable things in the patch:
- nsICSSAnonBoxPseudo and nsICSSPseudoElement now inherit from nsStaticAtom,
not nsAtom, because that's more precise.
- Each static atoms array now has an enum associated with it, which is used in
various ways.
- In the big comment about the macros at the top of nsStaticAtom.h, the pre-
and post-expansion forms are now shown interleaved. The interleaving reduces
duplication and makes the comment much easier to read and maintain. The
comment also has an introduction that explains the constraints and goals of
the implementation.
- The SUBCLASS macro variations are gone. There are few enough users of these
macros now that always passing the atom type has become simpler.
MozReview-Commit-ID: 1GmfKidLjaU
--HG--
extra : rebase_source : 2352590101fc6693ba388f885ca4714a42963943
Kris Maglione
arthur.iakab
Andrea Marchesini
Sylvestre Ledru
Ehsan Akhgari
Andrew McCreight
Andreea Pavel
Jorg K
Tooru Fujisawa
Valentin Gosu
Kirk Steuber
Henri Sivonen
David Parks
Coroiu Cristina
Ciure Andrei
Eric Rahm
Brian Hackett
Nicholas Nethercote
aceman
Marco Castelluccio
Nathan Froyd
Mike Conley
Cameron McCormack
Narcis Beleuzu
Masatoshi Kimura
Shane Caraveo
Brindusan Cristian
Chris Peterson
Josh Aas
Andi-Bogdan Postelnicu
shindli
Paolo Amadini
Dorel Luca
Honza Bambas
Csoregi Natalia
Emilio Cobos Álvarez
Markus Stange
Marco Bonardo
Michael Kaply
Sebastian Hengst
Tristan Bourvon