This patch begins re-implements ReadableStreams using WebIDL and DOM technology (vs the existing JS streams implementation). Some more background is [here](https://docs.google.com/document/d/1MWRkF32KV60ngOY-Ip4PnKbCMvl6VK_Y9QLED8MJJxg/edit#)
This is guarded under a configure flag `--enable-dom-streams`
1. ByteStreams and ReadableStream.tee will come in future patches.
2. I intentionally crash in other parts of the DOM that require streams (Fetch, Response, Blob), until the integration work is done in future patches.
My current plan for that integration doesn't involve re-creating the alternative 'external streams' API from SpiderMonkey's implementation, but I have yet to do enough development to verify that will work.
Differential Revision: https://phabricator.services.mozilla.com/D122643
This basically reverts the changes in 5caa81103c00 (bug 1435671). In that bug
we switched from having a templated method to using a templated function
that returned a lambda because the templated method caused a binary size
regression on windows (MSVC). Since Firefox 67 we no longer support MSVC.
Using a lambda also required capturing the arguments by value, so it was
slightly inefficient.
This patch removes NS_MutatorMethod and makes the Apply method a template.
This improves perfomance as we can just pass the arguments to the called
function, without worrying about needing to copy them.
Since MSVC is not supported anymore, and clang and gcc didn't report a
binary size regression, this is a much better solution.
Differential Revision: https://phabricator.services.mozilla.com/D122081
This basically reverts the changes in 5caa81103c00 (bug 1435671). In that bug
we switched from having a templated method to using a templated function
that returned a lambda because the templated method caused a binary size
regression on windows (MSVC). Since Firefox 67 we no longer support MSVC.
Using a lambda also required capturing the arguments by value, so it was
slightly inefficient.
This patch removes NS_MutatorMethod and makes the Apply method a template.
This improves perfomance as we can just pass the arguments to the called
function, without worrying about needing to copy them.
Since MSVC is not supported anymore, and clang and gcc didn't report a
binary size regression, this is a much better solution.
Differential Revision: https://phabricator.services.mozilla.com/D122081
Bug 1215723 introduced a mechanism whereby DataStorage data would be propagated
to content processes to avoid the IPC calls involved in querying if hosts were
HSTS. With a low number of content processes, this was a reasonable approach.
However, with Fission and the proliferation of content processes, propagating
changes in DataStorage data to every content process wakes up unrelated
processes and is inefficient. This patch restores the behavior that
nsISiteSecurityService and DataStorage is not available to content processes.
Additionally, bug 1626076 made it possible to use DataStorage directly from the
socket process. However, as of bug 1650356, this is no longer necessary, so
this patch removes that behavior as well.
Differential Revision: https://phabricator.services.mozilla.com/D118207
There's a pattern of clearing JS things when calling mozilla::DropJSObjects,
but mozilla::DropJSObjects already clears the JS things itself by calling
CycleCollectedJSRuntime::RemoveJSHolder.
Differential Revision: https://phabricator.services.mozilla.com/D115885
- Add missing include directives and forward declarations.
- Remove some extra include directives.
- Add missing namespace qualifications.
- Move include directives out of namespace in toolkit/xre/GlobalSemaphore.h
Differential Revision: https://phabricator.services.mozilla.com/D98894
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
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 a later part of this patch series, this will be necessary to handle cases
when BackgroundParentImpl* (or other PBackgroundParent subclasses) are passed to
RemoteLazyInputStreamParent::Create, as previously this would've caused an
undefined linker symbol error. By using an explicit overload set, we can move
the subclass conversion to the caller, and avoid this issue.
Differential Revision: https://phabricator.services.mozilla.com/D101801
In a later part of this patch series, this will be necessary to handle cases
when BackgroundParentImpl* (or other PBackgroundParent subclasses) are passed to
RemoteLazyInputStreamParent::Create, as previously this would've caused an
undefined linker symbol error. By using an explicit overload set, we can move
the subclass conversion to the caller, and avoid this issue.
Differential Revision: https://phabricator.services.mozilla.com/D101801
In a later part of this patch series, this will be necessary to handle cases
when BackgroundParentImpl* (or other PBackgroundParent subclasses) are passed to
RemoteLazyInputStreamParent::Create, as previously this would've caused an
undefined linker symbol error. By using an explicit overload set, we can move
the subclass conversion to the caller, and avoid this issue.
Differential Revision: https://phabricator.services.mozilla.com/D101801
In a later part of this patch series, this will be necessary to handle cases
when BackgroundParentImpl* (or other PBackgroundParent subclasses) are passed to
RemoteLazyInputStreamParent::Create, as previously this would've caused an
undefined linker symbol error. By using an explicit overload set, we can move
the subclass conversion to the caller, and avoid this issue.
Differential Revision: https://phabricator.services.mozilla.com/D101801
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
Allow-list all Python code in tree for use with the black linter, and re-format all code in-tree accordingly.
To produce this patch I did all of the following:
1. Make changes to tools/lint/black.yml to remove include: stanza and update list of source extensions.
2. Run ./mach lint --linter black --fix
3. Make some ad-hoc manual updates to python/mozbuild/mozbuild/test/configure/test_configure.py -- it has some hard-coded line numbers that the reformat breaks.
4. Make some ad-hoc manual updates to `testing/marionette/client/setup.py`, `testing/marionette/harness/setup.py`, and `testing/firefox-ui/harness/setup.py`, which have hard-coded regexes that break after the reformat.
5. Add a set of exclusions to black.yml. These will be deleted in a follow-up bug (1672023).
# ignore-this-changeset
Differential Revision: https://phabricator.services.mozilla.com/D94045
Allow-list all Python code in tree for use with the black linter, and re-format all code in-tree accordingly.
To produce this patch I did all of the following:
1. Make changes to tools/lint/black.yml to remove include: stanza and update list of source extensions.
2. Run ./mach lint --linter black --fix
3. Make some ad-hoc manual updates to python/mozbuild/mozbuild/test/configure/test_configure.py -- it has some hard-coded line numbers that the reformat breaks.
4. Make some ad-hoc manual updates to `testing/marionette/client/setup.py`, `testing/marionette/harness/setup.py`, and `testing/firefox-ui/harness/setup.py`, which have hard-coded regexes that break after the reformat.
5. Add a set of exclusions to black.yml. These will be deleted in a follow-up bug (1672023).
# ignore-this-changeset
Differential Revision: https://phabricator.services.mozilla.com/D94045
Allow-list all Python code in tree for use with the black linter, and re-format all code in-tree accordingly.
To produce this patch I did all of the following:
1. Make changes to tools/lint/black.yml to remove include: stanza and update list of source extensions.
2. Run ./mach lint --linter black --fix
3. Make some ad-hoc manual updates to python/mozbuild/mozbuild/test/configure/test_configure.py -- it has some hard-coded line numbers that the reformat breaks.
4. Add a set of exclusions to black.yml. These will be deleted in a follow-up bug (1672023).
# ignore-this-changeset
Differential Revision: https://phabricator.services.mozilla.com/D94045
The MOZ_MUST_USE macro is defined as clang's and gcc's nonstandard __attribute__((warn_unused_result)). Now that we compile as C++17 by default (bug 1560664), we can replace MOZ_MUST_USE with C++17's standard [[nodiscard]] attribute.
Differential Revision: https://phabricator.services.mozilla.com/D89237
We avoid going through Substring which imposes a limit on the string length of
INT32_MAX and failing a MOZ_RELEASE_ASSERT otherwise.
This adds a new `Base64EncodeAppend` function that takes 8-bit char input and
produces 16-bit char output, and appends to an existing string, which is what
we need here to avoid doing a large copy. Base64EncodeHelper is generalized
to accomodate for that.
So in addition to fixing the defect, this also optimizes performance and
memory usage.
Differential Revision: https://phabricator.services.mozilla.com/D87413
Previously similar logic existed in BlobURLProtocolHandler, which has now been removed, since such checks are now for parent process only and should be abstracted from BlobURLProtocolHandler.
Depends on D75293
Differential Revision: https://phabricator.services.mozilla.com/D81126
BlobURLProtocolHandler no longer passes blobImpl pointer to BlobURLChannel. Instead, acquisition and handling of blob data is offloaded to BlobURLInputStream.
Differential Revision: https://phabricator.services.mozilla.com/D75293
Reading from this stream type should be the preferred way to consume data from blob url. When created in the parent process, it requests blob data locally from BlobURLProtocolHandler. When created in a content process, it makes BlobURLDataRequest IPC call to the parent process. Should be wrapped in a nsBufferedInputStream, because ReadSegments() is currently not implemented for this stream type.
Differential Revision: https://phabricator.services.mozilla.com/D75292
Previously similar logic existed in BlobURLProtocolHandler, which has now been removed, since such checks are now for parent process only and should be abstracted from BlobURLProtocolHandler.
Depends on D75293
Differential Revision: https://phabricator.services.mozilla.com/D81126
BlobURLProtocolHandler no longer passes blobImpl pointer to BlobURLChannel. Instead, acquisition and handling of blob data is offloaded to BlobURLInputStream.
Differential Revision: https://phabricator.services.mozilla.com/D75293
Reading from this stream type should be the preferred way to consume data from blob url. When created in the parent process, it requests blob data locally from BlobURLProtocolHandler. When created in a content process, it makes BlobURLDataRequest IPC call to the parent process. Should be wrapped in a nsBufferedInputStream, because ReadSegments() is currently not implemented for this stream type.
Differential Revision: https://phabricator.services.mozilla.com/D75292
Before P1, GetCurrentThreadSerialEventTarget would have always returned the same data as NS_GetCurrentThread, making the comment incorrect Now it will properly return the running TaskQueue if any.
This change of name more clearly exposes what they are doing, as we aren't always dealing with threads directly; but a nsISerialEventTarget
Differential Revision: https://phabricator.services.mozilla.com/D80354
Initially, IPCInternal{Request,Response} had contained IPCStreams which would
result in unecessary copying when sending the objects over IPC. The patch
makes these streams either:
1) ParentToParentStream (just a UUID)
2) ParentToChildStream (a PIPCBlobInputStream actor, acting as a handle)
3) ChildToParentStream (a real IPCStream)
These three types are union-ed together by the BodyStreamVariant IPDL structure.
This structure replaces the IPCStream members in IPCInternal{Request,Response}
so that, depending on the particular IPDL protocol, we can avoid cloning streams
and just pass handles/IDs instead.
As a side effect, this makes file-backed Response objects cloneable. Initially,
these Responses would be backed by an nsFileInputStream, which is not cloneable
outside the parent process. They are now backed by IPCBlobInputStreams, which
are cloneable.
One thing that's not really satisfactory (IMO), is the manual management of
IPCBlobInputStreamStorage so that no streams are leaked, e.g. if we store a
stream in the IPCBlobInputStreamStorage but fail to send an IPC message and
therefore fail to remove the stream from storage on the other side of the IPC
boundary (only parent-to-parent in this case).
Differential Revision: https://phabricator.services.mozilla.com/D73173
Initially, IPCInternal{Request,Response} had contained IPCStreams which would
result in unecessary copying when sending the objects over IPC. The patch
makes these streams either:
1) ParentToParentStream (just a UUID)
2) ParentToChildStream (a PIPCBlobInputStream actor, acting as a handle)
3) ChildToParentStream (a real IPCStream)
These three types are union-ed together by the BodyStreamVariant IPDL structure.
This structure replaces the IPCStream members in IPCInternal{Request,Response}
so that, depending on the particular IPDL protocol, we can avoid cloning streams
and just pass handles/IDs instead.
As a side effect, this makes file-backed Response objects cloneable. Initially,
these Responses would be backed by an nsFileInputStream, which is not cloneable
outside the parent process. They are now backed by IPCBlobInputStreams, which
are cloneable.
One thing that's not really satisfactory (IMO), is the manual management of
IPCBlobInputStreamStorage so that no streams are leaked, e.g. if we store a
stream in the IPCBlobInputStreamStorage but fail to send an IPC message and
therefore fail to remove the stream from storage on the other side of the IPC
boundary (only parent-to-parent in this case).
Differential Revision: https://phabricator.services.mozilla.com/D73173
Initially, IPCInternal{Request,Response} had contained IPCStreams which would
result in unecessary copying when sending the objects over IPC. The patch
makes these streams either:
1) ParentToParentStream (just a UUID)
2) ParentToChildStream (a PIPCBlobInputStream actor, acting as a handle)
3) ChildToParentStream (a real IPCStream)
These three types are union-ed together by the BodyStreamVariant IPDL structure.
This structure replaces the IPCStream members in IPCInternal{Request,Response}
so that, depending on the particular IPDL protocol, we can avoid cloning streams
and just pass handles/IDs instead.
As a side effect, this makes file-backed Response objects cloneable. Initially,
these Responses would be backed by an nsFileInputStream, which is not cloneable
outside the parent process. They are now backed by IPCBlobInputStreams, which
are cloneable.
One thing that's not really satisfactory (IMO), is the manual management of
IPCBlobInputStreamStorage so that no streams are leaked, e.g. if we store a
stream in the IPCBlobInputStreamStorage but fail to send an IPC message and
therefore fail to remove the stream from storage on the other side of the IPC
boundary (only parent-to-parent in this case).
Differential Revision: https://phabricator.services.mozilla.com/D73173
These tests used <iframe mozbrowser> for convenience, mostly forcing
themselves to only run in non-e10s mode in the process, but none of them
really have any need to.
Differential Revision: https://phabricator.services.mozilla.com/D70745
These tests used <iframe mozbrowser> for convenience, mostly forcing
themselves to only run in non-e10s mode in the process, but none of them
really have any need to.
Differential Revision: https://phabricator.services.mozilla.com/D70745
These tests used <iframe mozbrowser> for convenience, mostly forcing
themselves to only run in non-e10s mode in the process, but none of them
really have any need to.
Differential Revision: https://phabricator.services.mozilla.com/D70745
For the usecases in dom/file, I'm not so sure how to get the global at
callsites, so I let aIsSystemPrincipal and aCrossOriginIsolated to be false for
now.
Differential Revision: https://phabricator.services.mozilla.com/D63905
--HG--
extra : moz-landing-system : lando
ssummar
msub2
Evgenia Kotovich
Christoph Kerschbaumer
Noemi Erli
Alexandru Michis
Matthew Gaudet
Mark Banner
Kagami Sascha Rosylight
Iulian Moraru
Andi-Bogdan Postelnicu
Valentin Gosu
Kashav Madan
Nika Layzell
Dana Keeler
Kris Maglione
Peter Van der Beken
Kris Wright
Simon Giesecke
smolnar
Tom Schuster
Bogdan Tara
Brindusan Cristian
Csoregi Natalia
Kartik Gautam
Dorel Luca
Karl Tomlinson
Sylvestre Ledru
Butkovits Atila
Ricky Stewart
Andi-Bogdan Postelnicu
Chris Peterson
Andrea Marchesini
ssengupta
Razvan Maries
Jean-Yves Avenard
Nicholas Nethercote
Perry Jiang
owlishDeveloper
Matt Woodrow
Ciure Andrei
Tom Tung
Andreas Farre