* Test that the preloaded image is actually used and that no preload requests
are made if the resource shouldn't be preloaded
Differential Revision: https://phabricator.services.mozilla.com/D139740
Currently only same origin requests are preloaded and preloads in the
secure context. This may change in the future to match W3C decisions and
Chromes behavior.
Also only images get preloaded. This will change in the future to cover
asset types.
Currently the anchor isn't parsed correctly yet[1], so this will be
fixed in a future patch.
On non-2xx responses of the main document all ongoing preloads get
canceled. Already completed preloads don't get affected and are in the
cache.
It is currently untested whether unused preloads don't have side effects.
Another future patch should cover adding the preload to the devtools.
[1]: https://datatracker.ietf.org/doc/html/rfc8288#section-3.2
Differential Revision: https://phabricator.services.mozilla.com/D137885
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
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
This interface should no longer be required due to the changes in part 1
limiting the complexity of IPCStream instances and limiting the number of file
descriptors which a single stream can attach to a message.
Removing this interface is necessary to serialize nsIInputStream instances over
arbitrary toplevel protocols and non-protocol IPC in the future.
Differential Revision: https://phabricator.services.mozilla.com/D141039
This gives us various positive benefits, such as using a shared memory ring
buffer for faster communication, not having data streaming being bound to the
thread which transferred the nsIInputStream (which is often the main thread),
and the ability for some backpressure to be applied to data streaming.
After this change, the "delayed start" parameter for IPCStream serialization is
less relevant, as backpressure will serve a similar purpose. It will still be
used to determine whether or not to use RemoteLazyInputStream when serializing
from the parent process.
Differential Revision: https://phabricator.services.mozilla.com/D141038
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 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
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
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
This interface should no longer be required due to the changes in part 1
limiting the complexity of IPCStream instances and limiting the number of file
descriptors which a single stream can attach to a message.
Removing this interface is necessary to serialize nsIInputStream instances over
arbitrary toplevel protocols and non-protocol IPC in the future.
Differential Revision: https://phabricator.services.mozilla.com/D141039
This gives us various positive benefits, such as using a shared memory ring
buffer for faster communication, not having data streaming being bound to the
thread which transferred the nsIInputStream (which is often the main thread),
and the ability for some backpressure to be applied to data streaming.
After this change, the "delayed start" parameter for IPCStream serialization is
less relevant, as backpressure will serve a similar purpose. It will still be
used to determine whether or not to use RemoteLazyInputStream when serializing
from the parent process.
Differential Revision: https://phabricator.services.mozilla.com/D141038
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 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
Manuel Bucher
Noemi Erli
Cristian Tuns
Nika Layzell
Thomas Wisniewski
Butkovits Atila
Tooru Fujisawa
Neil Deakin
Kershaw Chang
Iulian Moraru
Hannah Peuckmann