This increases the minimum resolution to 1080 and dropped the ratio to
1% from 5%. This should give a better video playback experience for
people using resist fingerprinting and better matches the values that
clients without that pref give.
Differential Revision: https://phabricator.services.mozilla.com/D142842
Before we would stick all prefs into an immutable shared memory
region and clear our HashMap.
Now we will stick all non-sanitized prefs into the immutable
shared memory region, save the sanitized prefs in a list
temporarily, clear the hashmap, and then repopulate the hashmap
with the sanitized prefs.
As a bit of underlying complexity, to do this we must do some
tricks with the Pref Name Arena which is a chunk of memory
dedicated to storing pref names. That goes away (and we want to
wipe it to save space) - so we just need to move the sanitized
pref names to a new arena.
Depends on D141421
Differential Revision: https://phabricator.services.mozilla.com/D141422
We busted browser_preferences_usage.js by looking up a
preference too many times.
The reason we are now exceeding the pref-reading limit for
this pref is that inside ShouldSanitizePreference all of
our calls to Preferences::Something(pref_name) are causing
pref lookups. _Most_ of the time when we are in
ShouldSanitizePreference, we got there from a place that has
the actual pref object; so change the function to take in a
Pref object.
Unfortunately, there is a place we do need to look it up
by name, and that's in Static Pref getters, so we need to
keep that function around (and expose it in Preferences.h)
To minimize code duplication (i.e. not having the exact same
code for ShouldSanitizePreference(Pref) and
ShouldSanitizePreference(PrefWrapper) we do some templating
tricks because even though they expose the same API, they are
not in a class hierarchy where we could just make one function
for a base class.
Depends on D141420
Differential Revision: https://phabricator.services.mozilla.com/D141421
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
For all subprocesses, if a preference is in the blocklist,
sanitize it. (This preserves the IPC optimization behavior,
kind of. We now generate IPC traffic when we didn't before,
but we omit the value. Values were previously capped at 4 KiB
now they're 0 bytes.)
For Web Content processes, we sanitize a preference if it is
in the blocklist, or if does not have a Default value (i.e.
it is dynamically named). There is an exception list for
dynamically named preferences we know we need though.
In subprocesses, we know if a preference was sanitized
by checking its Sanitized bit.
Depends on D141416
Differential Revision: https://phabricator.services.mozilla.com/D141417
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
A couple places where it might be a web content process
still pass 'false' - this will be corrected in a later
patch.
Depends on D141410
Differential Revision: https://phabricator.services.mozilla.com/D141411
Before we would stick all prefs into an immutable shared memory
region and clear our HashMap.
Now we will stick all non-sanitized prefs into the immutable
shared memory region, save the sanitized prefs in a list
temporarily, clear the hashmap, and then repopulate the hashmap
with the sanitized prefs.
As a bit of underlying complexity, to do this we must do some
tricks with the Pref Name Arena which is a chunk of memory
dedicated to storing pref names. That goes away (and we want to
wipe it to save space) - so we just need to move the sanitized
pref names to a new arena.
Depends on D141421
Differential Revision: https://phabricator.services.mozilla.com/D141422
We busted browser_preferences_usage.js by looking up a
preference too many times.
The reason we are now exceeding the pref-reading limit for
this pref is that inside ShouldSanitizePreference all of
our calls to Preferences::Something(pref_name) are causing
pref lookups. _Most_ of the time when we are in
ShouldSanitizePreference, we got there from a place that has
the actual pref object; so change the function to take in a
Pref object.
Unfortunately, there is a place we do need to look it up
by name, and that's in Static Pref getters, so we need to
keep that function around (and expose it in Preferences.h)
To minimize code duplication (i.e. not having the exact same
code for ShouldSanitizePreference(Pref) and
ShouldSanitizePreference(PrefWrapper) we do some templating
tricks because even though they expose the same API, they are
not in a class hierarchy where we could just make one function
for a base class.
Depends on D141420
Differential Revision: https://phabricator.services.mozilla.com/D141421
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
For all subprocesses, if a preference is in the blocklist,
sanitize it. (This preserves the IPC optimization behavior,
kind of. We now generate IPC traffic when we didn't before,
but we omit the value. Values were previously capped at 4 KiB
now they're 0 bytes.)
For Web Content processes, we sanitize a preference if it is
in the blocklist, or if does not have a Default value (i.e.
it is dynamically named). There is an exception list for
dynamically named preferences we know we need though.
In subprocesses, we know if a preference was sanitized
by checking its Sanitized bit.
Depends on D141416
Differential Revision: https://phabricator.services.mozilla.com/D141417
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
A couple places where it might be a web content process
still pass 'false' - this will be corrected in a later
patch.
Depends on D141410
Differential Revision: https://phabricator.services.mozilla.com/D141411
Before we would stick all prefs into an immutable shared memory
region and clear our HashMap.
Now we will stick all non-sanitized prefs into the immutable
shared memory region, save the sanitized prefs in a list
temporarily, clear the hashmap, and then repopulate the hashmap
with the sanitized prefs.
As a bit of underlying complexity, to do this we must do some
tricks with the Pref Name Arena which is a chunk of memory
dedicated to storing pref names. That goes away (and we want to
wipe it to save space) - so we just need to move the sanitized
pref names to a new arena.
Depends on D141421
Differential Revision: https://phabricator.services.mozilla.com/D141422
We busted browser_preferences_usage.js by looking up a
preference too many times.
The reason we are now exceeding the pref-reading limit for
this pref is that inside ShouldSanitizePreference all of
our calls to Preferences::Something(pref_name) are causing
pref lookups. _Most_ of the time when we are in
ShouldSanitizePreference, we got there from a place that has
the actual pref object; so change the function to take in a
Pref object.
Unfortunately, there is a place we do need to look it up
by name, and that's in Static Pref getters, so we need to
keep that function around (and expose it in Preferences.h)
To minimize code duplication (i.e. not having the exact same
code for ShouldSanitizePreference(Pref) and
ShouldSanitizePreference(PrefWrapper) we do some templating
tricks because even though they expose the same API, they are
not in a class hierarchy where we could just make one function
for a base class.
Depends on D141420
Differential Revision: https://phabricator.services.mozilla.com/D141421
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
For all subprocesses, if a preference is in the blocklist,
sanitize it. (This preserves the IPC optimization behavior,
kind of. We now generate IPC traffic when we didn't before,
but we omit the value. Values were previously capped at 4 KiB
now they're 0 bytes.)
For Web Content processes, we sanitize a preference if it is
in the blocklist, or if does not have a Default value (i.e.
it is dynamically named). There is an exception list for
dynamically named preferences we know we need though.
In subprocesses, we know if a preference was sanitized
by checking its Sanitized bit.
Depends on D141416
Differential Revision: https://phabricator.services.mozilla.com/D141417
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
A couple places where it might be a web content process
still pass 'false' - this will be corrected in a later
patch.
Depends on D141410
Differential Revision: https://phabricator.services.mozilla.com/D141411
Before we would stick all prefs into an immutable shared memory
region and clear our HashMap.
Now we will stick all non-sanitized prefs into the immutable
shared memory region, save the sanitized prefs in a list
temporarily, clear the hashmap, and then repopulate the hashmap
with the sanitized prefs.
As a bit of underlying complexity, to do this we must do some
tricks with the Pref Name Arena which is a chunk of memory
dedicated to storing pref names. That goes away (and we want to
wipe it to save space) - so we just need to move the sanitized
pref names to a new arena.
Depends on D141421
Differential Revision: https://phabricator.services.mozilla.com/D141422
We busted browser_preferences_usage.js by looking up a
preference too many times.
The reason we are now exceeding the pref-reading limit for
this pref is that inside ShouldSanitizePreference all of
our calls to Preferences::Something(pref_name) are causing
pref lookups. _Most_ of the time when we are in
ShouldSanitizePreference, we got there from a place that has
the actual pref object; so change the function to take in a
Pref object.
Unfortunately, there is a place we do need to look it up
by name, and that's in Static Pref getters, so we need to
keep that function around (and expose it in Preferences.h)
To minimize code duplication (i.e. not having the exact same
code for ShouldSanitizePreference(Pref) and
ShouldSanitizePreference(PrefWrapper) we do some templating
tricks because even though they expose the same API, they are
not in a class hierarchy where we could just make one function
for a base class.
Depends on D141420
Differential Revision: https://phabricator.services.mozilla.com/D141421
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
For all subprocesses, if a preference is in the blocklist,
sanitize it. (This preserves the IPC optimization behavior,
kind of. We now generate IPC traffic when we didn't before,
but we omit the value. Values were previously capped at 4 KiB
now they're 0 bytes.)
For Web Content processes, we sanitize a preference if it is
in the blocklist, or if does not have a Default value (i.e.
it is dynamically named). There is an exception list for
dynamically named preferences we know we need though.
In subprocesses, we know if a preference was sanitized
by checking its Sanitized bit.
Depends on D141416
Differential Revision: https://phabricator.services.mozilla.com/D141417
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
A couple places where it might be a web content process
still pass 'false' - this will be corrected in a later
patch.
Depends on D141410
Differential Revision: https://phabricator.services.mozilla.com/D141411
Before we would stick all prefs into an immutable shared memory
region and clear our HashMap.
Now we will stick all non-sanitized prefs into the immutable
shared memory region, save the sanitized prefs in a list
temporarily, clear the hashmap, and then repopulate the hashmap
with the sanitized prefs.
As a bit of underlying complexity, to do this we must do some
tricks with the Pref Name Arena which is a chunk of memory
dedicated to storing pref names. That goes away (and we want to
wipe it to save space) - so we just need to move the sanitized
pref names to a new arena.
Depends on D141421
Differential Revision: https://phabricator.services.mozilla.com/D141422
We busted browser_preferences_usage.js by looking up a
preference too many times.
The reason we are now exceeding the pref-reading limit for
this pref is that inside ShouldSanitizePreference all of
our calls to Preferences::Something(pref_name) are causing
pref lookups. _Most_ of the time when we are in
ShouldSanitizePreference, we got there from a place that has
the actual pref object; so change the function to take in a
Pref object.
Unfortunately, there is a place we do need to look it up
by name, and that's in Static Pref getters, so we need to
keep that function around (and expose it in Preferences.h)
To minimize code duplication (i.e. not having the exact same
code for ShouldSanitizePreference(Pref) and
ShouldSanitizePreference(PrefWrapper) we do some templating
tricks because even though they expose the same API, they are
not in a class hierarchy where we could just make one function
for a base class.
Depends on D141420
Differential Revision: https://phabricator.services.mozilla.com/D141421
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
For all subprocesses, if a preference is in the blocklist,
sanitize it. (This preserves the IPC optimization behavior,
kind of. We now generate IPC traffic when we didn't before,
but we omit the value. Values were previously capped at 4 KiB
now they're 0 bytes.)
For Web Content processes, we sanitize a preference if it is
in the blocklist, or if does not have a Default value (i.e.
it is dynamically named). There is an exception list for
dynamically named preferences we know we need though.
In subprocesses, we know if a preference was sanitized
by checking its Sanitized bit.
Depends on D141416
Differential Revision: https://phabricator.services.mozilla.com/D141417
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
A couple places where it might be a web content process
still pass 'false' - this will be corrected in a later
patch.
Depends on D141410
Differential Revision: https://phabricator.services.mozilla.com/D141411
The Firefox in flatpak has no access to the wireless networks to determine
accurate geolocation. We have to use the location portal instead which
provides the current location based on the nearby wireless accesspoints
or other methods.
Differential Revision: https://phabricator.services.mozilla.com/D142329
The Firefox in flatpak has no access to the wireless networks to determine
accurate geolocation. We have to use the location portal instead which
provides the current location based on the nearby wireless accesspoints
or other methods.
Differential Revision: https://phabricator.services.mozilla.com/D142329
Put mozilla.widget.raise-on-setfocus, widget.transparent-windows
and widget.wayland.use-move-to-rect in StaticPrefList.yaml, then
get rid of gRaiseWindows, gTransparentWindows and gUseMoveToRect
from widget/gtk/nsWindow.cpp.
Differential Revision: https://phabricator.services.mozilla.com/D143885
When downloading a file, we check for existing mime types and construct
a new one if it's unrecognized. Mime types have a flag,
alwaysAskBeforeHandling, that determines whether the unknown content
type dialog should be opened before handling the file. Before bug
1733492, the default value for that flag was simply true. Since the new
downloads flow is intended to avoid unnecessary steps, the default value
was changed to the inverted value of the new downloads panel
improvements pref. This patch adds a new pref that the mime info
constructor will read in configuring the flag's value. If the
improvements pref is not enabled, then the flag will be true, so the UCT
dialog will open. If the improvements pref is enabled, then it'll use
the value of the new pref. Also add a an interface for the pref to the
about:preferences UI, and automatically migrate a false value for
browser.download.improvements_to_download_panel to a true value for this
pref. I'm updating some tangentially related test files since they
happen to be touched slightly by this change. Strictly speaking they
would still work, but if the pref value was somehow changed from the
default they would fail.
Differential Revision: https://phabricator.services.mozilla.com/D143002
We did it for early-beta in bug 1632143, for nightly even earlier. No
regressions in two years, sounds like flipping is warranted.
Differential Revision: https://phabricator.services.mozilla.com/D143496
This sets up prefs so by default any release will use the content signature path
for GMP updates, rather than cert pinning. This intentionally leaves in place
the old cert pinning machinery so that we can still use if we need to
- Compare the new and old for things like debugging.
- Revert these changes in the case of regressions (either by shipping a patch or
something like normandy).
This patch is also small to enable it to be uplifted easily.
Once we're sure this new path is good, a larger patch can follow up to remove
the cert pinning code + rework our tests.
Differential Revision: https://phabricator.services.mozilla.com/D141891
When downloading a file, we check for existing mime types and construct
a new one if it's unrecognized. Mime types have a flag,
alwaysAskBeforeHandling, that determines whether the unknown content
type dialog should be opened before handling the file. Before bug
1733492, the default value for that flag was simply true. Since the new
downloads flow is intended to avoid unnecessary steps, the default value
was changed to the inverted value of the new downloads panel
improvements pref. This patch adds a new pref that the mime info
constructor will read in configuring the flag's value. If the
improvements pref is not enabled, then the flag will be true, so the UCT
dialog will open. If the improvements pref is enabled, then it'll use
the value of the new pref. Also add a an interface for the pref to the
about:preferences UI, and automatically migrate a false value for
browser.download.improvements_to_download_panel to a true value for this
pref. I'm updating some tangentially related test files since they
happen to be touched slightly by this change. Strictly speaking they
would still work, but if the pref value was somehow changed from the
default they would fail.
Differential Revision: https://phabricator.services.mozilla.com/D143002
This patch extends the expiration time of the storage access permission
given by the redirect heuristic to 30 days. This matches to the
expiration time of the permission given by other heuristics.
Differential Revision: https://phabricator.services.mozilla.com/D142431
To support magnifying glass on GeckoView, I would like to add `dragcaret`
event and, clientX and clientX in CaretStateChangedEvent chrome event.
Actually, accessible caret fires `presscaret` and `releasecaret` when
accessbile caret is pressed or released. But when dragging this caret, no
chrome event is fired. Since magnifying glass listens to moving this caret,
I would like `dargcaret` for GeckoView.
Also, Users' dragging point is necessary to set better position of magnifying
glass windows. So I also want client point of dragging point on `presscaret`
and `dragcaret` event.
This event and properties are on layout.accessiblecaret.magnifier.enabled=true,
So this can be only for GeckoView.
Differential Revision: https://phabricator.services.mozilla.com/D137965
This should reduce our memory footprint by no longer requiring us to
fully rasterize SVG images when used as an image map. It should also
move the cost of rasterization off the main thread during display list
building to worker threads during scene building.
Differential Revision: https://phabricator.services.mozilla.com/D143190
This proxies the printing operation via the parent like we do everywhere
else.
Otherwise we try to create anonymous files in the child process which is
forbidden.
Differential Revision: https://phabricator.services.mozilla.com/D142971
Bug 1753146 doubled the success threshold for Windows only, but browser/base/content/browser-gestureSupport.js at https://searchfox.org/mozilla-central/rev/26a1b0fce12e6dd495a954c542bb1e7bd6e0d548/browser/base/content/browser-gestureSupport.js#739 multiplies the values present in swipe events by 4 to determine opacity; so it it assuming the value 0.25 is the success threshold.
This patch first reverts bug 1753146 and then fixes it in a different way, so that the success threshold still has the same value and hence we don't need to modify browser-gestureSupport.js (so that all the code depending on this is in one one). We double the kWholePagePixelSize on Windows (and turn it into a pref) so that we don't regress bug 1753146. This is equivalent because the numeric value computed in SwipeTracker::ComputeSwipeSuccess will be the same, since the values mGestureAmount and mCurrentVelocity all have a division by kWholePagePixelSize when they are computed in SwipeTracker::ProcessEvent. There is one difference though: the velocity twitch tolerance comparison in SwipeTracker::ComputeSwipeSuccess will be slightly different. I think that's okay though.
Differential Revision: https://phabricator.services.mozilla.com/D140185
WMFDecoderModule will now cache supported stream types upon decoder process startup. Only one task will be dispatched to the MTA thread where all support will be determined at once.
MFTDecoder now will call all functions necessary to fully free memory on its WMF objects.
Preference media.wmf.vp9.enabled can now be changed without restarting.
Differential Revision: https://phabricator.services.mozilla.com/D142002
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 adds OnEvent hooks to DrawTargetWebgl for various events so that
profile counters may be maintained each frame. These profile counters
try to determine if a software fallback happened or an uncacheable event
occurs that requires either uploading data to the GPU or reading back
from the GPU, events which can cause substantial slowdown if they happen
repeatedly even without an explicit fallback to software rasterization.
When it is determined a threshold has been reached (as controlled by
some prefs), RequiresRefresh() in PersistentBufferProvider is used to
signal that we should recreate the PersistentBufferProvider of a different
type and thus disable acceleration.
Differential Revision: https://phabricator.services.mozilla.com/D142646
WMFDecoderModule will now cache supported stream types upon decoder process startup. Only one task will be dispatched to the MTA thread where all support will be determined at once.
MFTDecoder now will call all functions necessary to fully free memory on its WMF objects.
Preference media.wmf.vp9.enabled can now be changed without restarting.
Differential Revision: https://phabricator.services.mozilla.com/D142002
Two noteworthy details that may seem random otherwise:
* Moving values around in nsStyleDisplay is needed so that the struct
remains under the size limit that we have to avoid jumping allocator
buckets.
* All the test expectation churn is because tests depend on
`container-type: size` parsing to run, and now they run. Tests for
the relevant bits I implemented are passing, with the only exception
of some `container-name-computed.html` failures which are
https://github.com/w3c/csswg-drafts/issues/7181. Safari agrees with
us there.
Other notes when looking at the spec and seeing how it matches the
implementation:
* `container` syntax doesn't match spec, but matches tests and sanity:
https://github.com/w3c/csswg-drafts/issues/7180
* `container-type` syntax doesn't _quite_ match spec, but matches tests
and I think it's a spec bug since the definition for the missing
keyword is gone:
https://github.com/w3c/csswg-drafts/issues/7179
Differential Revision: https://phabricator.services.mozilla.com/D142419
This patch extends the expiration time of the storage access permission
given by the redirect heuristic to 30 days. This matches to the
expiration time of the permission given by other heuristics.
Differential Revision: https://phabricator.services.mozilla.com/D142431
Make Link and SVGAElement agree on XLink handling, and make it more
explicit that SVGAElement needs to be a bit more special for SMIL.
Remove dead MathML XLink code.
Differential Revision: https://phabricator.services.mozilla.com/D142546
Add media.rdd-process.max-crashes preference value to control how many times we restard RDD process before we throw decoding error message.
Differential Revision: https://phabricator.services.mozilla.com/D142326
The Baseline Requirements no longer require an OCSP URI for EV certificate
intermediates. Since OneCRL covers intermediates anyways, OCSP checking for
intermediates can be skipped entirely.
Differential Revision: https://phabricator.services.mozilla.com/D142369
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 replaces the previous process selection infrastructure with a
new setup implemented entirely in C++, which should more accurately
track the set of processes in use, and should encourage re-use of the
existing content process when navigating by not counting the current
tab.
This approach intentionally allows for process switching to another
process during navigation if there is uneven load between processes to
encourage balanced process use.
I think this may also fix some of the session restore issues with many
tabs using the same process, rather than being spread over 4, as we now
track a tab earlier in its lifecycle before the BrowserParent instance
is created.
Differential Revision: https://phabricator.services.mozilla.com/D126405
Depends on D141468
All usage of this preference should now have been removed.
We don't plan to disable devtools completely, but only to disable the F12 shortcut.
Differential Revision: https://phabricator.services.mozilla.com/D141469
The patch adds two prefs to control whether we ignore the less
restricted referrer policies for top navigation. For Web compatibility,
we still need to allow less restricted referrer policies for top
navigations. We will allow it in the standard mode and still disallow it
in the strict mode and private browsing window.
Differential Revision: https://phabricator.services.mozilla.com/D141866
Depends on D141468
All usage of this preference should now have been removed.
We don't plan to disable devtools completely, but only to disable the F12 shortcut.
Differential Revision: https://phabricator.services.mozilla.com/D141469
They are just convenience for :root[lwthemetextcolor="light"] (and dark,
respectively), but they generally shouldn't be used for dark mode
theming. In the past it was the only way to do it but now we have
prefers-color-scheme.
While at it, change lwthemetextcolor to be "lwtheme-brighttext" for
consistency with similar code we have for popups etc, and move it to
_setDarkModeAttributes.
While at it, remove layout.css.moz-lwtheme.content.enabled (which is
false always, we unshipped these from content successfully).
Differential Revision: https://phabricator.services.mozilla.com/D141593
I think it's fair to say that this is not a new feature anymore. This avoids
showing the notification every time a developer uses devtools on a local build
or so (with a clean profile).
Differential Revision: https://phabricator.services.mozilla.com/D142000
The reason why we change the `OMTAdiv`'s width value is that with the original
200px width, the elment in question will be overflowed in our mochitest iframe.
Differential Revision: https://phabricator.services.mozilla.com/D141812
* TextEncoder stream tests now fail, rather than error
* WritableStreams are exosed on worker interfacess now; and broken-then is fixed too
* Fix interface semantics
Differential Revision: https://phabricator.services.mozilla.com/D141125
This patch just adds the plumbing to allow for baked in blocklist rules
or the downloadable blocklist to prevent certain configurations from
getting WebGPU. It does not add any rules.
It also changes us from allowing WebGPU only in nightly, including
tests, to not release and not beta. This allows try to run the WebGPU
tests as expected, since even try builds forked from mozilla-central are
not considered nightly builds by CI (or so it seems).
Differential Revision: https://phabricator.services.mozilla.com/D141682
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
This allows themes to override our light / dark theme heuristics if they
choose to, so that we don't have to complicate the heuristics too much.
This is specially useful for themes with images, where the image might
be "light", but still have enough contrast with light text. A good
example is the theme mentioned in bug 1749837 comment 0.
The semantics are:
* color_scheme: If set, overrides the general "toolbar theme" (so
window and context menu appearance and so on), otherwise we fall back
to heuristics.
* content_color_scheme: If set, overrides the color scheme for the
content area. Otherwise we fall back to color_scheme if present, or
heuristics otherwise.
One thing that I didn't include was a sort of "system" option, which
might be useful to say "this theme is neutral, and works both for light
and dark themes". Let me know if you think that's a must-have, otherwise
I think it's probably worth deferring to a follow-up if it's needed at
all.
Differential Revision: https://phabricator.services.mozilla.com/D136354
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
Cristian Tuns
Butkovits Atila
Emilio Cobos Álvarez
John Schanck
Jeff Muizelaar
Kagami Sascha Rosylight
Marian-Vasile Laza
Kershaw Chang
Tom Ritter
Molnar Sandor
Kelsey Gilbert
Dmitrij Feller
Sebastian Hengst
Andrew Osmond
Bobby Holley
Tom Schuster
Bob Owen
Sean Feng
Cosmin Sabou
Yury Delendik
Paul Zuehlcke
Luca Greco
Jan Horak
David Parks
Chun-Min Chang
Razvan Cojocaru
Shane Hughes
criss
Bryce Seager van Dyk
Tim Huang
Henrik Skupin
Nicolas Silva
Makoto Kato
sotaro
Alexandre Lissy
irwp
Niklas Baumgardner
Timothy Nikkel
Byron Campen
Zaggy1024
Jan Rio Krause
Frederik Braun
Lee Salzman
Edgar Chen
John Lin
Tim Giles
Ryan Hunt
Jamie Nicol
Narcis Beleuzu
Ryan VanderMeulen
stransky
Dana Keeler
Csoregi Natalia
Eitan Isaacson
Andreas Farre
Paul Adenot
Nika Layzell
Julian Descottes
Norisz Fay
Hiroyuki Ikezoe
Matthew Gaudet
Nick Alexander
Chris Peterson