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
This patch implements that the referrer protection can be disabled by
the ETP toggle. When ETP is toggled off, it will stop the protection for
iframe and sub-resource loads. Also, it will stop the protection for a
loading to a site that has ETP disabled.
This patch also makes
CookieJarSettings::UpdateIsOnContentBlockingAllowList() be more
efficient when calling it multiple times.
Differential Revision: https://phabricator.services.mozilla.com/D142249
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
- nsHttpConnection now has states. Currently only proxy setup phase is added to the states.
- The states are used in nsHttpConnection::OnSocketWritable tto make the code more understandable.
- Some pieces of selfcontained code are extracted from nsHttpConnection::OnHeadersAvailable, i.e. HandleTunnelResponse and HandleWebSocketResponse
Differential Revision: https://phabricator.services.mozilla.com/D138714
- nsHttpConnection now has states. Currently only proxy setup phase is added to the states.
- The states are used in nsHttpConnection::OnSocketWritable tto make the code more understandable.
- Some pieces of selfcontained code are extracted from nsHttpConnection::OnHeadersAvailable, i.e. HandleTunnelResponse and HandleWebSocketResponse
Differential Revision: https://phabricator.services.mozilla.com/D138714
This removes a part of the erroneous scheme-comparison and the logging
that was implemented in those functions. The tests for that logging were
also removed.
Differential Revision: https://phabricator.services.mozilla.com/D136229
Firefox background tasks use a new temporary profile directory for
every invocation. We would like to write as little data as possible
into the temporary profile directory in this mode. This patch allows
to make the persistent cookie storage discard cookies just like
private cookie storage.
This approach simply uses that the base `CookieStorage` class is close
to sufficient already. There may be a performance impact with more
virtual invocations, but none of these functions seem likely to be
hot.
Differential Revision: https://phabricator.services.mozilla.com/D139910
Before this change, the collection of typedefs to include in IPDL
protocols was being performed in the _DecorateWithCXXStuff pass of
lower.py. This pass iterates over all included headers, including
recursively, so will also visit headers included by headers you import.
The recursive behaviour caused issues because importing and
forward-declaring imported types is non-recursive, looking at exported
types only one layer deep. This could lead to typedefs being generated
in IPDL protocols referencing types which could never be named by the
IPDL code, and which had no definition in c++, leading to build errors.
This patch changes the logic to instead happen during the
_GenerateProtocolActorCode pass of lower.py, which is also where
required forward declarations and imports are handled, allowing us to
keep the set of typedefs generated more tightly in sync with the actual
set of types available to the actor.
This required some changes in client code which was relying on
incorrectly generated typedefs, however these types have now been fixed.
Differential Revision: https://phabricator.services.mozilla.com/D141032
This Nimbus experiment code was added in bug 1719070 to test if sending a "Firefox 100" UA string causes any major webcompat problems.
The moz.build change was added in bug 1724635 to fix a Thunderbird build break. MOZ_BUILD_APP_IS_BROWSER = true when building Firefox, false when building Thunderbird.
Differential Revision: https://phabricator.services.mozilla.com/D126408
The idea in this patch is like D99680, but the difference is that mFrecencyArray now contains CacheIndexRecordWrapper.
This should be able to help us track why CacheIndexRecordWrapper is released before removing it from mFrecencyArray.
Differential Revision: https://phabricator.services.mozilla.com/D139469
And in one case, #include "mozilla/ProfilerThreadState.h" where only `AUTO_PROFILER_THREAD_WAKE` is used.
Depends on D140172
Differential Revision: https://phabricator.services.mozilla.com/D140173
This patch is to delay starting `UntrustedModulesProcessor` to avoid
processing a massive amount of loaded modules in the browser process
during startup.
To achive that, this patch introduces "unblock-untrusted-modules-thread"
notification. Before the notification, `UntrustedModulesProcessor` is
created but marked as not ready. This means the processor does not
go beyond `ScheduleNonEmptyQueueProcessing`. Once the notification is
observed, we propagate it to all existing child processes, and afterward
`UntrustedModulesProcessor` in new processes will be marked ready from
the beginning.
Differential Revision: https://phabricator.services.mozilla.com/D140123
This patch is to delay starting `UntrustedModulesProcessor` to avoid
processing a massive amount of loaded modules in the browser process
during startup.
To achive that, this patch introduces "unblock-untrusted-modules-thread"
notification. Before the notification, `UntrustedModulesProcessor` is
created but marked as not ready. This means the processor does not
go beyond `ScheduleNonEmptyQueueProcessing`. Once the notification is
observed, we propagate it to all existing child processes, and afterward
`UntrustedModulesProcessor` in new processes will be marked ready from
the beginning.
Differential Revision: https://phabricator.services.mozilla.com/D140123
Automatically generated rewrites of all ParamTraits and IPDLParamTraits
implementations in-tree to use IPC::Message{Reader,Writer}.
Differential Revision: https://phabricator.services.mozilla.com/D140004
This change does not build without the automatically rewritten changes from
part 3c, as every IPC::ParamTraits and IPDLParamTraits implementation needs to
be updated at once, but these are the manual changes which are required and not
handled by the automatic script.
Differential Revision: https://phabricator.services.mozilla.com/D140001
This will allow the types to be more easily automatically substituted in place
of `IPC::Message`, as the type will already be declared in places it is used.
Differential Revision: https://phabricator.services.mozilla.com/D140000
This patch is to delay starting `UntrustedModulesProcessor` to avoid
processing a massive amount of loaded modules in the browser process
during startup.
To achive that, this patch introduces "unblock-untrusted-modules-thread"
notification. Before the notification, `UntrustedModulesProcessor` is
created but marked as not ready. This means the processor does not
go beyond `ScheduleNonEmptyQueueProcessing`. Once the notification is
observed, we propagate it to all existing child processes, and afterward
`UntrustedModulesProcessor` in new processes will be marked ready from
the beginning.
Differential Revision: https://phabricator.services.mozilla.com/D140123
This patch is to delay starting `UntrustedModulesProcessor` to avoid
processing a massive amount of loaded modules in the browser process
during startup.
To achive that, this patch introduces "unblock-untrusted-modules-thread"
notification. Before the notification, `UntrustedModulesProcessor` is
created but marked as not ready. This means the processor does not
go beyond `ScheduleNonEmptyQueueProcessing`. Once the notification is
observed, we propagate it to all existing child processes, and afterward
`UntrustedModulesProcessor` in new processes will be marked ready from
the beginning.
Differential Revision: https://phabricator.services.mozilla.com/D140123
With this patch, we'll skip the `RestrictConnections` cehck when creating a speculative connection for Alt-svc validation.
Differential Revision: https://phabricator.services.mozilla.com/D139952
This removes a part of the erroneous scheme-comparison and the logging
that was implemented in those functions. The tests for that logging were
also removed.
Differential Revision: https://phabricator.services.mozilla.com/D136229
When the pc.close() calls in PeerConnection.jsm were removed, tests that did
not explicitly call pc.close() would result in situations where DataChannel
shutdown ran first, which resulted in DataChannels hanging around after
DataChannel ran its global shutdown code. So, we stop using xpcom-shutdown to
prompt DataChannel to shut down, and instead use ShutdownBlockingTicket to
ensure that shutdown does not proceed until DataChannel is cleaned up, which
naturally results from the PeerConnectionCtx shutdown code. However,
ShutdownBlockingTicket blocks xpcom-will-shutdown, not xpcom-shutdown, which
resulted in PeerConnectionCtx not getting an opportunity to run its shutdown
code, which then led to shutdown hangs. So, PeerConnectionCtx runs its shutdown
code at xpcom-will-shutdown.
Differential Revision: https://phabricator.services.mozilla.com/D139210
Butkovits Atila
Nika Layzell
ffxbld
Andreas Farre
edguloien
John Schanck
Norisz Fay
Barret Rennie
Peter Van der Beken
Cristian Tuns
Mike Hommey
Tom Ritter
Kershaw Chang
Timothy Nikkel
Cosmin Sabou
Mathieu Leplatre
Karl Tomlinson
june wilde
Marian-Vasile Laza
Chris Peterson
Molnar Sandor
Dana Keeler
Jan Rio Krause
Mark Banner
Frederik Braun
Jonathan Watt
Manuel Bucher
Emilio Cobos Álvarez
Kagami Sascha Rosylight
criss
Tim Huang
Gijs Kruitbosch
Csoregi Natalia
Ryan VanderMeulen
Randell Jesup
Dragana Damjanovic
Tom Schuster
Tom Schuster
Nick Alexander
Noemi Erli
Sebastian Hengst
Olli Pettay
Gerald Squelart
Toshihito Kikuchi
Valentin Gosu
Mathew Hodson
Byron Campen
Andreea Pavel