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 bug was reported by Danilo Ramos of Eideticom, Inc. It has
lain in wait 13 years before being found! The bug was introduced
in zlib 1.2.2.2, with the addition of the Z_FIXED option. That
option forces the use of fixed Huffman codes. For rare inputs with
a large number of distant matches, the pending buffer into which
the compressed data is written can overwrite the distance symbol
table which it overlays. That results in corrupted output due to
invalid distances, and can result in out-of-bound accesses,
crashing the application.
The fix here combines the distance buffer and literal/length
buffers into a single symbol buffer. Now three bytes of pending
buffer space are opened up for each literal or length/distance
pair consumed, instead of the previous two bytes. This assures
that the pending buffer cannot overwrite the symbol table, since
the maximum fixed code compressed length/distance is 31 bits, and
since there are four bytes of pending space for every three bytes
of symbol space.
Differential Revision: https://phabricator.services.mozilla.com/D142231
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
We have this experimented in EARLY_BETA_OR_EARLIER for a while, and
it's been looking good. So let's enable it everywhere!
Differential Revision: https://phabricator.services.mozilla.com/D140793
For avoiding simple back-out of the patches when we get serious regression
reports, we should have a pref to disable the new pref.
Differential Revision: https://phabricator.services.mozilla.com/D140475
We need to hide the pointer when we detect a keypress and unhide it when we get any mouse event or window deactivation. We only do this if the Windows "Hide pointer while typing" setting is turned on (it is on by default). We currently also put this behind the Firefox pref "widget.windows.hide_cursor_when_typing".
Differential Revision: https://phabricator.services.mozilla.com/D139896
Background: The X11 protocol has a very permissive security model;
clients have essentially full access to the windows of other clients,
and to global resources like input devices. Previously, our sandbox
policy for content processes needed to allow access to the X server;
this limited its effectiveness against a dedicated attacker.
This patch turns on the `security.sandbox.content.headless` pref added
in bug 1640345, which removes the sandbox policy rules that allowed
making new X11 connections, as well as opening the Xauthority file,
reading hardware info needed by Mesa, etc. It also runs content
processes in headless mode (whence the name) so they won't connect to a
display server at startup.
This also removes access to the Wayland compositor: the sandbox policy
never allowed that (as of when socket connections became default-deny),
but now content processes won't connect to it at startup. Wayland is
more capability-oriented so this is less significant for security, but at
a minimum it removes unnecessary attack surface.
Note that if the `webgl.out-of-process` pref is turned off, WebGL
will break unless `security.sandbox.content.headless` is also turned
off. (Similarly, `widget.non-native-theme.enabled` is needed to render
scrollbars and form controls in content.) As a result, this patch
adjusts the job definitions used by CI to test in-process WebGL so that
that they will continue to work.
Differential Revision: https://phabricator.services.mozilla.com/D138613
This patch changes the way we parse JavaScript coming from Necko while loading
web pages, by adding an about:config flag named
javascript.options.delazification.strategy which is used to select between:
0 - On Demand
1 - Concurrent Depth First
255 - Parse Everything Eagerly
Previously, we moved from On-demand delazification, to parsing everything
eagerly to improve responsiveness of the browser, but we knew that more room for
optimization exists.
This toogle is meant to explore the space of delazification strategies, such
that we can parse functions of JavaScript files on an helper thread, while the
JavaScript file is being executed on the main thread. The space of
delazification strategies goes from ordering the order in which functions are
processed, as well as filtering functions which are processed. Not all functions
have to be delazified, and if the main thread needs a function which is not
parsed yet, it will fallback to parsing it on-demand.
Differential Revision: https://phabricator.services.mozilla.com/D138034
A number of tests (and expectations) are updated here to either avoid
accidentally relying on the size of Courier New on Windows, or to
explicitly use Courier New instead of monospace, where it's harder to
work out how to rewrite the test correctly.
Differential Revision: https://phabricator.services.mozilla.com/D87222
It's already disabled since 96 and now is late 97 cycle in the release channel,
but I've not gotten regression reports about this. Therefore, we should get
rid of it from the tree completely, then, we can make
`HTMLEditor::CreateAndInsertElementWithTransaction` greater for its callers.
Depends on D139717
Differential Revision: https://phabricator.services.mozilla.com/D139718
I had this written somewhere in a branch, but given bug 1419151, I
cleaned it up a bit and turned it into an actual patch that works.
Behind a pref for now, because at the very least it needs:
* Support for some testing-only functions.
* Support for custom icons (for web extensions and so on).
The key point is that this adds the relevant code to map a XUL menu to a
GMenuModel, which we could then export via
`g_dbus_connection_export_menu_model()`, which seems like a much simpler
approach to support stuff like bug 1419151.
See the MenuModel class in NativeMenuGtk as for how is this done.
Differential Revision: https://phabricator.services.mozilla.com/D139845
We no longer need to use the print portal, the gtk is doing that for us
for the system print dialog and the native print dialog uses GtkPrintJob
which sends jobs to the cups print backend.
Differential Revision: https://phabricator.services.mozilla.com/D139594
It seems Blink / WebKit run this even if in the same document, but it
seems less-potentially-breaking to restrict this to the cross-document
case.
Though at least on the test-case it seems it's loading from the same
origin, which is a bit dubious to restrict...
Differential Revision: https://phabricator.services.mozilla.com/D138369
We sanitize a preference (when sending from the parent
process) 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.
Differential Revision: https://phabricator.services.mozilla.com/D138685
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...
Differential Revision: https://phabricator.services.mozilla.com/D138682
While we do so, also add a boolean argument to indicate
if we are in a _Content_ process or some other type of
subprocess, which I expect we will need later.
Differential Revision: https://phabricator.services.mozilla.com/D138681
We want to eventually crash if a blocklisted preference
is accessed. In order to do this, we do need to
populate the preference in the pref hashmap of the
subprocess; otherwise when we look up a blocklisted
pref we will just not find anything. We could try to
put the blocklist check at that point; but this won't
work for StaticPrefs; we'd also need to put the blocklist
check there.
Performing a list iteration and string comparison on
every Static Pref call is not acceptable when we can
just populate a bit and check it.
Differential Revision: https://phabricator.services.mozilla.com/D138679
This patch changes the way we parse JavaScript coming from Necko while loading
web pages, by adding an about:config flag named
javascript.options.delazification.strategy which is used to select between:
0 - On Demand
1 - Concurrent Depth First
255 - Parse Everything Eagerly
Previously, we moved from On-demand delazification, to parsing everything
eagerly to improve responsiveness of the browser, but we knew that more room for
optimization exists.
This toogle is meant to explore the space of delazification strategies, such
that we can parse functions of JavaScript files on an helper thread, while the
JavaScript file is being executed on the main thread. The space of
delazification strategies goes from ordering the order in which functions are
processed, as well as filtering functions which are processed. Not all functions
have to be delazified, and if the main thread needs a function which is not
parsed yet, it will fallback to parsing it on-demand.
Differential Revision: https://phabricator.services.mozilla.com/D138034
This also adjusts our mochitests so that they know we're exposing the WebMIDI
objects publicly, modifies the way permissions are granted and adjusts our
web platform tests to account for known failures.
Differential Revision: https://phabricator.services.mozilla.com/D137486
This patch changes the way we parse JavaScript coming from Necko while loading
web pages, by adding an about:config flag named
javascript.options.delazification.strategy which is used to select between:
0 - On Demand
1 - Concurrent Depth First
255 - Parse Everything Eagerly
Previously, we moved from On-demand delazification, to parsing everything
eagerly to improve responsiveness of the browser, but we knew that more room for
optimization exists.
This toogle is meant to explore the space of delazification strategies, such
that we can parse functions of JavaScript files on an helper thread, while the
JavaScript file is being executed on the main thread. The space of
delazification strategies goes from ordering the order in which functions are
processed, as well as filtering functions which are processed. Not all functions
have to be delazified, and if the main thread needs a function which is not
parsed yet, it will fallback to parsing it on-demand.
Differential Revision: https://phabricator.services.mozilla.com/D138034
This also adjusts our mochitests so that they know we're exposing the WebMIDI
objects publicly, modifies the way permissions are granted and adjusts our
web platform tests to account for known failures.
Differential Revision: https://phabricator.services.mozilla.com/D137486
Tom Ritter
Tom Schuster
Bob Owen
Mike Hommey
Sean Feng
Cosmin Sabou
Yury Delendik
Cristian Tuns
Paul Zuehlcke
Luca Greco
Marian-Vasile Laza
Jan Horak
Molnar Sandor
David Parks
Chun-Min Chang
Emilio Cobos Álvarez
Razvan Cojocaru
Shane Hughes
criss
Bryce Seager van Dyk
Butkovits Atila
Tim Huang
Kagami Sascha Rosylight
Henrik Skupin
Nicolas Silva
Andrew Osmond
Makoto Kato
sotaro
Alexandre Lissy
irwp
Niklas Baumgardner
Timothy Nikkel
Byron Campen
Jeff Muizelaar
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
Mark Adler
Nika Layzell
Julian Descottes
Norisz Fay
Randell Jesup
Kershaw Chang
Iulian Moraru
John Schanck
Hiroyuki Ikezoe
Matthew Gaudet
Nick Alexander
Chris Peterson
alwu
Noemi Erli
Miko Mynttinen
Molly Howell
Agi Sferro
Mike Conley
edguloien
Martin Robinson
Julia Cwiek
Dimi
Masayuki Nakano
Matthew Gregan
Dave Townsend
Jed Davis
Nicolas B. Pierron
Cameron McCormack
Valentin Gosu
Chris Martin
Tyler Kabaker
Gabriele Svelto
Shane Caraveo
mcheang
Sergey Galich