This disables the outdated, incorrect implementation of the
Reporting API. The current implementation was only enabled
on Nightly builds, but given its current state it does not
even make sense there.
Differential Revision: https://phabricator.services.mozilla.com/D149873
This disables the outdated, incorrect implementation of the
Reporting API. The current implementation was only enabled
on Nightly builds, but given its current state it does not
even make sense there.
Differential Revision: https://phabricator.services.mozilla.com/D149873
This disables the outdated, incorrect implementation of the
Reporting API. The current implementation was only enabled
on Nightly builds, but given its current state it does not
even make sense there.
Differential Revision: https://phabricator.services.mozilla.com/D149873
This disables the outdated, incorrect implementation of the
Reporting API. The current implementation was only enabled
on Nightly builds, but given its current state it does not
even make sense there.
Differential Revision: https://phabricator.services.mozilla.com/D149873
This API should no longer be necessary, as there's nothing tied to a specific
actor in the serialized IPCBlob form any longer, so the value can be directly
transferred without special handling or re-serialization.
Differential Revision: https://phabricator.services.mozilla.com/D148533
This is largely a straightforward find and replace of various methods, with the
unnecessary arguments removed and compiler errors fixed.
Differential Revision: https://phabricator.services.mozilla.com/D148532
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
This test always fails, and it should be always disabled, but for some reason
it is run in verify mode, on most (but not all) platforms.
Differential Revision: https://phabricator.services.mozilla.com/D146385
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
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 is a complete rewrite of RemoteLazyInputStream to run off of its own
toplevel protocol, rather than being managed by other protocols like
PBackground or PContent. This should improve performance thanks to no longer
needing to operate on a main or worker thread, and due to no longer needing the
migration step for the stream actor.
This also acts as a step towards no longer requiring a manager actor to
serialize input streams, as the type is now actor-agnostic, and should support
being sent over IPC between any pair of processes.
Differential Revision: https://phabricator.services.mozilla.com/D141040