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
* 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
In future parts, TaskQueue will require extra initialization to be performed
which cannot happen in a constructor, as it takes references to the TaskQueue
object itself, which will require the introduction of a helper method. This
patch switches all callers of the TaskQueue constructor to use the new method.
Differential Revision: https://phabricator.services.mozilla.com/D142604
Because we rely on the process switching code for replacing the
frameloaders for BFCache in the parent, we need to force the process
switch behaviour to PROCESS_BEHAVIOR_STANDARD if BFCache in the parent
is on.
Differential Revision: https://phabricator.services.mozilla.com/D144518
dom/media/platforms/wmf/WMFEncoderModule.cpp(31,5): error: unannotated fall-through between switch labels [-Werror,-Wimplicit-fallthrough]
case MediaDataEncoder::CodecType::VP9:
^
dom/media/platforms/wmf/WMFEncoderModule.cpp(31,5): note: insert '[[fallthrough]];' to silence this warning
case MediaDataEncoder::CodecType::VP9:
^
[[fallthrough]];
netwerk/test/gtest/TestNamedPipeService.cpp(212,5): error: unannotated fall-through between switch labels [-Werror,-Wimplicit-fallthrough]
default: // error
^
netwerk/test/gtest/TestNamedPipeService.cpp(212,5): note: insert '[[fallthrough]];' to silence this warning
default: // error
^
[[fallthrough]];
widget/windows/KeyboardLayout.cpp(1973,5): error: unannotated fall-through between switch labels [-Werror,-Wimplicit-fallthrough]
default:
^
widget/windows/KeyboardLayout.cpp(1973,5): note: insert 'U_FALLTHROUGH;' to silence this warning
default:
^
U_FALLTHROUGH;
widget/windows/WinMouseScrollHandler.cpp(633,5): error: unannotated fall-through between switch labels [-Werror,-Wimplicit-fallthrough]
case SB_PAGEDOWN:
^
widget/windows/WinMouseScrollHandler.cpp(633,5): note: insert 'U_FALLTHROUGH;' to silence this warning
case SB_PAGEDOWN:
^
U_FALLTHROUGH;
widget/windows/WinMouseScrollHandler.cpp(640,5): error: unannotated fall-through between switch labels [-Werror,-Wimplicit-fallthrough]
case SB_LINEDOWN:
^
widget/windows/WinMouseScrollHandler.cpp(640,5): note: insert 'U_FALLTHROUGH;' to silence this warning
case SB_LINEDOWN:
^
U_FALLTHROUGH;
widget/windows/nsLookAndFeel.cpp(188,5): error: unannotated fall-through between switch labels [-Werror,-Wimplicit-fallthrough]
case ColorID::MozMenuhovertext:
^
widget/windows/nsLookAndFeel.cpp(188,5): note: insert 'U_FALLTHROUGH;' to silence this warning
case ColorID::MozMenuhovertext:
^
U_FALLTHROUGH;
widget/windows/nsLookAndFeel.cpp(194,5): error: unannotated fall-through between switch labels [-Werror,-Wimplicit-fallthrough]
case ColorID::Highlighttext:
^
widget/windows/nsLookAndFeel.cpp(194,5): note: insert 'U_FALLTHROUGH;' to silence this warning
case ColorID::Highlighttext:
^
U_FALLTHROUGH;
widget/windows/nsLookAndFeel.cpp(469,15): error: unannotated fall-through between switch labels [-Werror,-Wimplicit-fallthrough]
case ABE_BOTTOM:
^
widget/windows/nsLookAndFeel.cpp(469,15): note: insert 'U_FALLTHROUGH;' to silence this warning
case ABE_BOTTOM:
^
U_FALLTHROUGH;
widget/windows/nsNativeThemeWin.cpp(2540,5): error: unannotated fall-through between switch labels [-Werror,-Wimplicit-fallthrough]
case StyleAppearance::Button:
^
widget/windows/nsNativeThemeWin.cpp(2540,5): note: insert 'U_FALLTHROUGH;' to silence this warning
case StyleAppearance::Button:
^
U_FALLTHROUGH;
widget/windows/nsNativeThemeWin.cpp(3278,5): error: unannotated fall-through between switch labels [-Werror,-Wimplicit-fallthrough]
case StyleAppearance::Checkbox:
^
widget/windows/nsNativeThemeWin.cpp(3278,5): note: insert 'U_FALLTHROUGH;' to silence this warning
case StyleAppearance::Checkbox:
^
U_FALLTHROUGH;
widget/windows/nsNativeThemeWin.cpp(3332,5): error: unannotated fall-through between switch labels [-Werror,-Wimplicit-fallthrough]
case StyleAppearance::Tabpanel:
^
widget/windows/nsNativeThemeWin.cpp(3332,5): note: insert 'U_FALLTHROUGH;' to silence this warning
case StyleAppearance::Tabpanel:
^
U_FALLTHROUGH;
widget/windows/nsNativeThemeWin.cpp(3461,5): error: unannotated fall-through between switch labels [-Werror,-Wimplicit-fallthrough]
case StyleAppearance::Menuarrow: {
^
widget/windows/nsNativeThemeWin.cpp(3461,5): note: insert 'U_FALLTHROUGH;' to silence this warning
case StyleAppearance::Menuarrow: {
^
U_FALLTHROUGH;
widget/windows/nsWindow.cpp(1339,5): error: unannotated fall-through between switch labels [-Werror,-Wimplicit-fallthrough]
case eWindowType_toplevel:
^
widget/windows/nsWindow.cpp(1339,5): note: insert 'U_FALLTHROUGH;' to silence this warning
case eWindowType_toplevel:
^
U_FALLTHROUGH;
widget/windows/nsWindow.cpp(1422,5): error: unannotated fall-through between switch labels [-Werror,-Wimplicit-fallthrough]
case eWindowType_toplevel:
^
widget/windows/nsWindow.cpp(1422,5): note: insert 'U_FALLTHROUGH;' to silence this warning
case eWindowType_toplevel:
^
U_FALLTHROUGH;
widget/windows/nsWindow.cpp(3379,5): error: unannotated fall-through between switch labels [-Werror,-Wimplicit-fallthrough]
case eTransparencyGlass:
^
widget/windows/nsWindow.cpp(3379,5): note: insert 'U_FALLTHROUGH;' to silence this warning
case eTransparencyGlass:
^
U_FALLTHROUGH;
widget/windows/nsWindow.cpp(5595,5): error: unannotated fall-through between switch labels [-Werror,-Wimplicit-fallthrough]
case WM_MOUSELEAVE: {
^
widget/windows/nsWindow.cpp(5595,5): note: insert 'U_FALLTHROUGH;' to silence this warning
case WM_MOUSELEAVE: {
^
U_FALLTHROUGH;
xpcom/io/SpecialSystemDirectory.cpp(572,5): error: unannotated fall-through between switch labels [-Werror,-Wimplicit-fallthrough]
case Win_Programs: {
^
xpcom/io/SpecialSystemDirectory.cpp(572,5): note: insert '[[fallthrough]];' to silence this warning
case Win_Programs: {
^
[[fallthrough]];
Differential Revision: https://phabricator.services.mozilla.com/D144668
This clarifies some of the members and arguments which were used in
DocumentLoadListener to make them more clear, adding documentation.
In addition to the simplifications of logic and improved naming, this
patch also moves the responsibility of managing StreamFilterRequest out
of DisconnectListeners so that stream listeners behave more
consistently, as the existing flag doesn't map well to whether or not
they should be cleared.
This was kept seperate from part 1 as it is largely a clarity
improvement, and may make it harder to see the important changes in that
part.
Depends on D143676
Differential Revision: https://phabricator.services.mozilla.com/D144747
This patch changes how we handle document loads which are being handled
internally but have Content-Disposition: attachment specified at the
DocumentLoadListener layer. This was done as process switching is
currently the only place during a load where we can change the target
BrowsingContext which the load will complete in.
The only situation where we should currently continue to deliver a
successful request to the default content-viewer despite
Content-Disposition: attachment being specified is when we choose to
handle a downloaded PDF internally, so this shouldn't impact other
cases.
The change is handled by forcing a process switch under the hood, and
opening a new browser window asynchronously to handle the process
switch, similar to how object and embed load upgrades are handled. This
is done using nsIBrowserDOMWindow to attempt to respect the user's
window opening preferences.
A small change to browser.js was also made to try to encourage the new
tab to be opened next to the previous tab, as well as to avoid starting
unnecessary new processes when creating the new browser window.
Differential Revision: https://phabricator.services.mozilla.com/D143675
In the following patch we are going to change the signature of
ShouldSanitizePreference to take a Pref object. Pref is only
known to the Preferences compilation unit; so to keep this member
(whose signature will change) we would need to expose the Pref
class. However it will only be a forward declaration, one could
not construct a Pref object in e.g. the gtest.
It is simpler to just remove the member entirely and call
ShouldSanitizePreference unconditionally - the member was only
used for the gtest, and while the gtest will be less robust
because of this change, it will still do some testing.
Depends on D141419
Differential Revision: https://phabricator.services.mozilla.com/D141420
To do the correct thing in Preferences::SerializePreferences
(which is used during subprocess startup) we need to know if
the destination process is a web content process or not.
We add parameters to
SharedPreferenceSerializer::SerializeToSharedMemory that let
us figure that out.
In Preferences::SerializePreferences we fix the call to
aShouldSanitizeFn to pass the correct destination.
Depends on D141415
Differential Revision: https://phabricator.services.mozilla.com/D141416
PreferenceUpdate is the IPC message notifying a child process
that a preference has been updated. To correctly decide whether
or not a value should be sanitized in it, we need to know
what type of destination process it is; we add parameters to
Preferences::GetPreference indicating that.
Inside of ToDomPref we call ShouldSanitizePreference to
correctly populate the sanitized bit.
Depends on D141412
Differential Revision: https://phabricator.services.mozilla.com/D141413
This simplifies the number of negations needed,
and makes things easy to understand. I think
anyway; I know that without renaming it I made
several annoying-to-diagnose negation errors...
Depends on D141411
Differential Revision: https://phabricator.services.mozilla.com/D141412
dom/media/ipc/RDDProcessManager.cpp(320,21): error: comparison of integers of different signs: 'base::ProcessId' (aka 'unsigned long') and 'int' [-Werror,-Wsign-compare]
gpuProcessPid != -1 ? gpuProcessPid : base::GetCurrentProcId();
~~~~~~~~~~~~~ ^ ~~
dom/media/ipc/RDDProcessManager.cpp(332,21): error: comparison of integers of different signs: 'base::ProcessId' (aka 'unsigned long') and 'int' [-Werror,-Wsign-compare]
if (gpuProcessPid != -1) {
~~~~~~~~~~~~~ ^ ~~
gfx/layers/ipc/SharedSurfacesParent.cpp(360,38): error: comparison of integers of different signs: 'base::ProcessId' (aka 'unsigned long') and 'int' [-Werror,-Wsign-compare]
if (!gpm || gpm->GPUProcessPid() != -1) {
~~~~~~~~~~~~~~~~~~~~ ^ ~~
ipc/glue/MessageChannel.cpp(2145,13): error: comparison of integers of different signs: 'int32_t' (aka 'int') and 'const base::ProcessId' (aka 'const unsigned long') [-Werror,-Wsign-compare]
if (pid != base::kInvalidProcessId &&
~~~ ^ ~~~~~~~~~~~~~~~~~~~~~~~
Differential Revision: https://phabricator.services.mozilla.com/D144688
In the following patch we are going to change the signature of
ShouldSanitizePreference to take a Pref object. Pref is only
known to the Preferences compilation unit; so to keep this member
(whose signature will change) we would need to expose the Pref
class. However it will only be a forward declaration, one could
not construct a Pref object in e.g. the gtest.
It is simpler to just remove the member entirely and call
ShouldSanitizePreference unconditionally - the member was only
used for the gtest, and while the gtest will be less robust
because of this change, it will still do some testing.
Depends on D141419
Differential Revision: https://phabricator.services.mozilla.com/D141420
To do the correct thing in Preferences::SerializePreferences
(which is used during subprocess startup) we need to know if
the destination process is a web content process or not.
We add parameters to
SharedPreferenceSerializer::SerializeToSharedMemory that let
us figure that out.
In Preferences::SerializePreferences we fix the call to
aShouldSanitizeFn to pass the correct destination.
Depends on D141415
Differential Revision: https://phabricator.services.mozilla.com/D141416
PreferenceUpdate is the IPC message notifying a child process
that a preference has been updated. To correctly decide whether
or not a value should be sanitized in it, we need to know
what type of destination process it is; we add parameters to
Preferences::GetPreference indicating that.
Inside of ToDomPref we call ShouldSanitizePreference to
correctly populate the sanitized bit.
Depends on D141412
Differential Revision: https://phabricator.services.mozilla.com/D141413
This simplifies the number of negations needed,
and makes things easy to understand. I think
anyway; I know that without renaming it I made
several annoying-to-diagnose negation errors...
Depends on D141411
Differential Revision: https://phabricator.services.mozilla.com/D141412
netwerk/protocol/http/Http2Compression.cpp:326:12: error: variable 'removedCount' set but not used [-Werror,-Wunused-but-set-variable]
uint32_t removedCount = 0;
^
netwerk/streamconv/converters/nsDirIndexParser.cpp:376:11: error: variable 'numItems' set but not used [-Werror,-Wunused-but-set-variable]
int32_t numItems = 0;
^
Differential Revision: https://phabricator.services.mozilla.com/D144144
In the following patch we are going to change the signature of
ShouldSanitizePreference to take a Pref object. Pref is only
known to the Preferences compilation unit; so to keep this member
(whose signature will change) we would need to expose the Pref
class. However it will only be a forward declaration, one could
not construct a Pref object in e.g. the gtest.
It is simpler to just remove the member entirely and call
ShouldSanitizePreference unconditionally - the member was only
used for the gtest, and while the gtest will be less robust
because of this change, it will still do some testing.
Depends on D141419
Differential Revision: https://phabricator.services.mozilla.com/D141420
To do the correct thing in Preferences::SerializePreferences
(which is used during subprocess startup) we need to know if
the destination process is a web content process or not.
We add parameters to
SharedPreferenceSerializer::SerializeToSharedMemory that let
us figure that out.
In Preferences::SerializePreferences we fix the call to
aShouldSanitizeFn to pass the correct destination.
Depends on D141415
Differential Revision: https://phabricator.services.mozilla.com/D141416
PreferenceUpdate is the IPC message notifying a child process
that a preference has been updated. To correctly decide whether
or not a value should be sanitized in it, we need to know
what type of destination process it is; we add parameters to
Preferences::GetPreference indicating that.
Inside of ToDomPref we call ShouldSanitizePreference to
correctly populate the sanitized bit.
Depends on D141412
Differential Revision: https://phabricator.services.mozilla.com/D141413
This simplifies the number of negations needed,
and makes things easy to understand. I think
anyway; I know that without renaming it I made
several annoying-to-diagnose negation errors...
Depends on D141411
Differential Revision: https://phabricator.services.mozilla.com/D141412
In the following patch we are going to change the signature of
ShouldSanitizePreference to take a Pref object. Pref is only
known to the Preferences compilation unit; so to keep this member
(whose signature will change) we would need to expose the Pref
class. However it will only be a forward declaration, one could
not construct a Pref object in e.g. the gtest.
It is simpler to just remove the member entirely and call
ShouldSanitizePreference unconditionally - the member was only
used for the gtest, and while the gtest will be less robust
because of this change, it will still do some testing.
Depends on D141419
Differential Revision: https://phabricator.services.mozilla.com/D141420
To do the correct thing in Preferences::SerializePreferences
(which is used during subprocess startup) we need to know if
the destination process is a web content process or not.
We add parameters to
SharedPreferenceSerializer::SerializeToSharedMemory that let
us figure that out.
In Preferences::SerializePreferences we fix the call to
aShouldSanitizeFn to pass the correct destination.
Depends on D141415
Differential Revision: https://phabricator.services.mozilla.com/D141416
PreferenceUpdate is the IPC message notifying a child process
that a preference has been updated. To correctly decide whether
or not a value should be sanitized in it, we need to know
what type of destination process it is; we add parameters to
Preferences::GetPreference indicating that.
Inside of ToDomPref we call ShouldSanitizePreference to
correctly populate the sanitized bit.
Depends on D141412
Differential Revision: https://phabricator.services.mozilla.com/D141413
This simplifies the number of negations needed,
and makes things easy to understand. I think
anyway; I know that without renaming it I made
several annoying-to-diagnose negation errors...
Depends on D141411
Differential Revision: https://phabricator.services.mozilla.com/D141412
In the following patch we are going to change the signature of
ShouldSanitizePreference to take a Pref object. Pref is only
known to the Preferences compilation unit; so to keep this member
(whose signature will change) we would need to expose the Pref
class. However it will only be a forward declaration, one could
not construct a Pref object in e.g. the gtest.
It is simpler to just remove the member entirely and call
ShouldSanitizePreference unconditionally - the member was only
used for the gtest, and while the gtest will be less robust
because of this change, it will still do some testing.
Depends on D141419
Differential Revision: https://phabricator.services.mozilla.com/D141420
To do the correct thing in Preferences::SerializePreferences
(which is used during subprocess startup) we need to know if
the destination process is a web content process or not.
We add parameters to
SharedPreferenceSerializer::SerializeToSharedMemory that let
us figure that out.
In Preferences::SerializePreferences we fix the call to
aShouldSanitizeFn to pass the correct destination.
Depends on D141415
Differential Revision: https://phabricator.services.mozilla.com/D141416
PreferenceUpdate is the IPC message notifying a child process
that a preference has been updated. To correctly decide whether
or not a value should be sanitized in it, we need to know
what type of destination process it is; we add parameters to
Preferences::GetPreference indicating that.
Inside of ToDomPref we call ShouldSanitizePreference to
correctly populate the sanitized bit.
Depends on D141412
Differential Revision: https://phabricator.services.mozilla.com/D141413
This simplifies the number of negations needed,
and makes things easy to understand. I think
anyway; I know that without renaming it I made
several annoying-to-diagnose negation errors...
Depends on D141411
Differential Revision: https://phabricator.services.mozilla.com/D141412
This patch changes the default behaviour of `download()`.
- Previous file-based behaviour was moved to `downloadToDisk()` and `deleteFromDisk()`. Existing consumers were migrated to avoid behaviour change.
- `download()` has now `{useCache: true}` by default, option was dropped, and `deleteCached()` is now `deleteDownloaded()`
Differential Revision: https://phabricator.services.mozilla.com/D141980
This patch changes the default behaviour of `download()`.
- Previous file-based behaviour was moved to `downloadToDisk()` and `deleteFromDisk()`. Existing consumers were migrated to avoid behaviour change.
- `download()` has now `{useCache: true}` by default, option was dropped, and `deleteCached()` is now `deleteDownloaded()`
Differential Revision: https://phabricator.services.mozilla.com/D141980
Before this change, all XPIDL constants were declared using an anonymous
`enum` rather than using a static constant. This change makes the
generated code more consistent with what is done in languages like Rust.
Some small changes were needed due to signed/unsigned comparison
warnings which were previously silent.
Differential Revision: https://phabricator.services.mozilla.com/D143090
Before this patch, nsISiteSecurityService APIs took "flags" parameters that
differentiated private contexts from not private contexts. However, these
parameters were redundant with respect to origin attributes, which led to some
confusion for consumers of these APIs. This patch removes these parameters in
favor of using origin attributes.
Differential Revision: https://phabricator.services.mozilla.com/D142901
Given that we only support samesite lax/strict/none in our storage schema,
it's useful to introduce a default value, as required by the spec.
However, that would it hard to distinguish between none/lax when we switch
the default.
So, instead of doing that we use the peculiarities of our current schema
to our advantage: There's a "sameSite" attribute and a "rawSameSite"
attribute, where the latter is the literal value we received from the
server. With this patch, we'll interpret the "sameSite" attribute
based on the laxByDefault pref. This also has the advantage that various
front-end code (e.g., in DevTools) is always reading the "sameSite"
value of nsICookies.
Differential Revision: https://phabricator.services.mozilla.com/D137460
Nika Layzell
Noemi Erli
Neil Deakin
Norisz Fay
Sebastian Hengst
Kershaw Chang
Karl Tomlinson
Csoregi Natalia
Mike Hommey
Andy Hochhaus
Iulian Moraru
Manuel Bucher
Butkovits Atila
ffxbld
Andreas Farre
edguloien
John Schanck
Barret Rennie
Peter Van der Beken
Cristian Tuns
Tom Ritter
Timothy Nikkel
Cosmin Sabou
Mathieu Leplatre
june wilde
Marian-Vasile Laza
Chris Peterson
Molnar Sandor
Dana Keeler
Jan Rio Krause
Mark Banner
Frederik Braun
Jonathan Watt
Emilio Cobos Álvarez
Kagami Sascha Rosylight
criss