Adds a new serial event target that executes the runnable immediately if already on the main thread. This allows then ThenValue to execute immediately instead of being dispatched to the back of the main thread event target, when possible.
Differential Revision: https://phabricator.services.mozilla.com/D146481
In order to know if the mIsThirdPartyContextToTopWindow was set in the
loadInfo of the channel, we use maybe to hold the value. So, we can know
if it was set before.
This patch also addes two methods in LoadInfo to clear and know if the
value is set.
Differential Revision: https://phabricator.services.mozilla.com/D146491
A UDP socket may receive a ConnecionReset error if a packet is sent to an unreachable port. This is not a reason to close the soccket.
Differential Revision: https://phabricator.services.mozilla.com/D146951
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
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
Previously, the check when reporting progress from a nsHttpTransaction would
always report no progress when a non-seekable input stream is used as the
request data stream. Before Part 5, we incorrectly always reported the
nsBufferedStream which we wrap request streams with as seekable, meaning that
this check would pass and the progress reporting would work.
This change relaxes the check to instead check for nsITellableStream which is
actually guaranteed by the nsBufferedStream wrapper, and provides the Tell
method being used.
Differential Revision: https://phabricator.services.mozilla.com/D144450
Previously this test was failing due to issues with upload streams not
being seekable. With the other changes in this bug, we now always
ensure that upload streams are consistently cloneable and seekable,
meaning that this issue should no longer occur, and we don't need to
re-start the request for it to succeed.
I also removed various pieces of dead code, as well as some logic
disabling bfcacheInParent, as that seems to no longer be required.
Differential Revision: https://phabricator.services.mozilla.com/D141777
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 interface is misleading, as it doesn't allow seeking the entire type
despite providing a `nsISeekableStream` interface, and is no longer necessary
due to the changes in an earlier part.
Differential Revision: https://phabricator.services.mozilla.com/D141046
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
Previously, nsBufferedStreams would always implement nsISeekableStream, whether
or not the underlying stream did, and would only fail when trying to seek. This
makes it much more difficult to compensate and correctly transform streams when
they need to be seekable.
Differential Revision: https://phabricator.services.mozilla.com/D141042
This type was originally made to be required to be seekable because a
non-seekable stream would lose the nsMIMEInputStream metadata information when
it was wrapped by the HTTP channel using PartiallySeekableInputStream, leading
to potential bugs.
Changes in a later part will change HTTP channel wrapping to ensure that this
metadata is preserved in all relevant cases, so this requirement can be
relaxed. This is important, as the check was previously being bypassed for
RemoteLazyInputStream in the content process, as nsBufferedInputStream would
incorrectly report that it implemented nsISeekableStream even if the underlying
stream wasn't seekable.
Differential Revision: https://phabricator.services.mozilla.com/D141041
Andrew Creskey
Kershaw Chang
Paul Zuehlcke
Hannah Peuckmann
Molnar Sandor
Mark Banner
Manuel Bucher
Tim Huang
Dragana Damjanovic
Tom Schuster
Cristian Tuns
Bryan Thrall
Butkovits Atila
Cosmin Sabou
ffxbld
Kagami Sascha Rosylight
Iulian Moraru
criss
Andrew McCreight
Sebastian Hengst
Nika Layzell