This creates the print.modal_print_preview.enabled pref to manage
whether the tab modal print UI should be used and creates some
files we'll need for the UI to use.
Differential Revision: https://phabricator.services.mozilla.com/D83445
We ran an experiment to assess the impact of the feature.
We could verify a significant performance impact on the opening times for the debugger.
It also led to a decrease in overall devtools usage and retention.
Therefore we are disabling the feature until we can implement it with better performance.
This should be implemented with https://bugzilla.mozilla.org/show_bug.cgi?id=1651522
Differential Revision: https://phabricator.services.mozilla.com/D83312
The kinda hacky mutex latch is preserved to avoid concerns with AtStartup prefs having
potential to deadlock when used in this subsystem.
Differential Revision: https://phabricator.services.mozilla.com/D83403
mozStorage used to read prefs on service init, because they could only be read
on the main-thread. When service init was moved earlier, it started trying
to read prefs too early, before the profile was set up, thus it ended up always
reading the default value.
This patch moves the only relevant pref to mirrored StaticPrefs that can be accessed
from different threads, and removes two preferences that apparently are not necessary
(they have been broken from a long time) for now.
In particular, providing a global synchronous setting is a footgun, each consumer should
decide about their synchronous needs, rather than abusing a dangerous "go fast" setting.
The page size is something we don't change from quite some time, and it's unlikely to be
used to run experiments in the wild before doing local measurements first, for which Try
builds are enough.
The remaining exclusiveLock pref is a bit controversial, because in general exclusive lock
is better for various reasons, and mostly it is necessary to use WAL on network shares.
Though developers may find it useful for debugging, and some third parties are doing
dangerous things (like copying over databases) to work around it, for which it's safer to
provide a less dangerous alternative.
Note exclusive lock only works on Unix-derived systems for now (no Windows implementation).
Finally, this introduces a fallback to exclusive lock, so that if a third party is using our
databases, so that we can't get an exclusive lock, we'll fallback to normal locking.
Differential Revision: https://phabricator.services.mozilla.com/D82717
Also we drop support for an independent-of-scroll/viewport capture, which
the old Tab Sharing supported, for security reasons (and we don't need it).
Differential Revision: https://phabricator.services.mozilla.com/D80974
In Bug 1638369 we added two new RSA-AES-GCM ciphersuites for web compatibility, but
did not add them to `all.js` so they weren't visible in about:config.
Since these are not mandatory ciphersuites to the TLS specification, they
should be configurable.
Differential Revision: https://phabricator.services.mozilla.com/D83192
Also we drop support for an independent-of-scroll/viewport capture, which
the old Tab Sharing supported, for security reasons (and we don't need it).
Differential Revision: https://phabricator.services.mozilla.com/D80974
Also we drop support for an independent-of-scroll/viewport capture, which
the old Tab Sharing supported, for security reasons (and we don't need it).
Differential Revision: https://phabricator.services.mozilla.com/D80974
This adds the boolean pref security.sandbox.content.headless (on Linux
only) which does two things:
1. Sets the MOZ_HEADLESS env var for content processes, so that they
don't initialize GTK and don't connect to the X server.
2. Disallows brokered access to parts of the filesystem used only for
graphics -- most critically connecting to the X11 socket itself, but
also opening GPU device nodes and the parts of sysfs used by Mesa, for
example.
This is experimental; use at your own risk.
Setting this pref will break native widgets, so it's also necessary to
set widget.disable-native-theme-for-content
Additionally, it breaks Flash and WebGL; see bug 1638466 for the latter.
Differential Revision: https://phabricator.services.mozilla.com/D81425
While we figure out the crashes we're seeing on beta (bug 1650654), this will
disable the intermediate preloading healer in late beta and release.
Differential Revision: https://phabricator.services.mozilla.com/D82588
This should be a relatively straightforward patch. Essentially, we implement
a wrapper class (and friends) around nsZipArchive (and friends), which transparently
caches entries from the underlying zip archive in the StartupCache. This will break
without changes to the StartupCache, made in the patch after this, which allow it
to be used off of the main thread, and outside the main process.
Depends on D77635
Differential Revision: https://phabricator.services.mozilla.com/D77634
Opening our Omnijars can be expensive, and it should be deferrable until after
startup is completed, provided we have a startup cache. In a previous patch in this
stack, we implemented caching of the zip central directory for omnijars, but we
still have to open the file in order to hand the object off to various omnijar
consumers. In a later patch, we will wrap nsZipArchive access in a class which
will allow us to transparently cache nsZipArchive results. These two get us
most of the way to not needing to read from the underlying omnijar files during
startup, but there are still nontrivial pieces, like nsZipFind for instance,
which we don't want to just duplicate inside of a wrapper class, so we would
like to sort out a way in which we can use an nsZipArchive class, but not
actually back it up with the real underlying file until we really need data
from it which we can't find in a cache.
Depends on D77633
Differential Revision: https://phabricator.services.mozilla.com/D78584
We would like to be able to defer opening the omnijar files until after startup
if the StartupCache has already been populated. Opening the omnijar files takes
a nontrivial time, at least on Windows, and almost everything in the omnijar
should be fairly compressible, and thus makes sense to live in the StartupCache.
See the last patch in this series for a little more discussion on numbers, but
tl;dr: we saw a 12% improvement in time to about:home being finished on reference
hardware with these changes together with the changes from the descendant patches.
Differential Revision: https://phabricator.services.mozilla.com/D77632
We do leak checking in AddressSanitizer builds. This runs as processes exit,
so we can't exit early. NS_FREE_PERMANENT_DATA should be set in any kind of
build that cares about leak checking.
Differential Revision: https://phabricator.services.mozilla.com/D82459
This should be a relatively straightforward patch. Essentially, we implement
a wrapper class (and friends) around nsZipArchive (and friends), which transparently
caches entries from the underlying zip archive in the StartupCache. This will break
without changes to the StartupCache, made in the patch after this, which allow it
to be used off of the main thread, and outside the main process.
Depends on D77635
Differential Revision: https://phabricator.services.mozilla.com/D77634
Opening our Omnijars can be expensive, and it should be deferrable until after
startup is completed, provided we have a startup cache. In a previous patch in this
stack, we implemented caching of the zip central directory for omnijars, but we
still have to open the file in order to hand the object off to various omnijar
consumers. In a later patch, we will wrap nsZipArchive access in a class which
will allow us to transparently cache nsZipArchive results. These two get us
most of the way to not needing to read from the underlying omnijar files during
startup, but there are still nontrivial pieces, like nsZipFind for instance,
which we don't want to just duplicate inside of a wrapper class, so we would
like to sort out a way in which we can use an nsZipArchive class, but not
actually back it up with the real underlying file until we really need data
from it which we can't find in a cache.
Depends on D77633
Differential Revision: https://phabricator.services.mozilla.com/D78584
We would like to be able to defer opening the omnijar files until after startup
if the StartupCache has already been populated. Opening the omnijar files takes
a nontrivial time, at least on Windows, and almost everything in the omnijar
should be fairly compressible, and thus makes sense to live in the StartupCache.
See the last patch in this series for a little more discussion on numbers, but
tl;dr: we saw a 12% improvement in time to about:home being finished on reference
hardware with these changes together with the changes from the descendant patches.
Differential Revision: https://phabricator.services.mozilla.com/D77632
We do leak checking in AddressSanitizer builds. This runs as processes exit,
so we can't exit early. NS_FREE_PERMANENT_DATA should be set in any kind of
build that cares about leak checking.
Differential Revision: https://phabricator.services.mozilla.com/D82459
This should be a relatively straightforward patch. Essentially, we implement
a wrapper class (and friends) around nsZipArchive (and friends), which transparently
caches entries from the underlying zip archive in the StartupCache. This will break
without changes to the StartupCache, made in the patch after this, which allow it
to be used off of the main thread, and outside the main process.
Depends on D77635
Differential Revision: https://phabricator.services.mozilla.com/D77634
Opening our Omnijars can be expensive, and it should be deferrable until after
startup is completed, provided we have a startup cache. In a previous patch in this
stack, we implemented caching of the zip central directory for omnijars, but we
still have to open the file in order to hand the object off to various omnijar
consumers. In a later patch, we will wrap nsZipArchive access in a class which
will allow us to transparently cache nsZipArchive results. These two get us
most of the way to not needing to read from the underlying omnijar files during
startup, but there are still nontrivial pieces, like nsZipFind for instance,
which we don't want to just duplicate inside of a wrapper class, so we would
like to sort out a way in which we can use an nsZipArchive class, but not
actually back it up with the real underlying file until we really need data
from it which we can't find in a cache.
Depends on D77633
Differential Revision: https://phabricator.services.mozilla.com/D78584
We would like to be able to defer opening the omnijar files until after startup
if the StartupCache has already been populated. Opening the omnijar files takes
a nontrivial time, at least on Windows, and almost everything in the omnijar
should be fairly compressible, and thus makes sense to live in the StartupCache.
See the last patch in this series for a little more discussion on numbers, but
tl;dr: we saw a 12% improvement in time to about:home being finished on reference
hardware with these changes together with the changes from the descendant patches.
Differential Revision: https://phabricator.services.mozilla.com/D77632
See https://bugzilla.mozilla.org/show_bug.cgi?id=1623943#c10 for more info,
but in short, this should be ready - there are a very small number of late
writes coming in via telemetry. I have gone through them, and the vast
majority of them are clearly nonissues. Of those remaining, which is on the
order of one hundredth of one percent of shutdowns, they are all going
through atomic file streams.
Differential Revision: https://phabricator.services.mozilla.com/D81609
Other than this, there hasn't been any other major regression since we
introduced that switch. I don't think there's a point in keeping it
around.
Differential Revision: https://phabricator.services.mozilla.com/D82297
The machinery to report janked animations is;
1) Store the partial pre-rendered animation id and the Animation object in a
hashtable in LayerManager
2) Store the animation id in the Animation object as well
3) When we detect jank, we send the animation id to the main-thread via an IPC
call
4) Find the Animation object with the id in the hashtable and update the
Animaiton
5) Whenever the partial pre-rendered Animation stop running on the compositor
i.e. the Animation finished normally, the Animation's target element is
changed, etc. etc., remove the Animation from the hashtable
Depends on D75731
Differential Revision: https://phabricator.services.mozilla.com/D75732
The machinery to report janked animations is;
1) Store the partial pre-rendered animation id and the Animation object in a
hashtable in LayerManager
2) Store the animation id in the Animation object as well
3) When we detect jank, we send the animation id to the main-thread via an IPC
call
4) Find the Animation object with the id in the hashtable and update the
Animaiton
5) Whenever the partial pre-rendered Animation stop running on the compositor
i.e. the Animation finished normally, the Animation's target element is
changed, etc. etc., remove the Animation from the hashtable
Differential Revision: https://phabricator.services.mozilla.com/D75732
- Adds a new "extensions.serviceWorkerRegister.allowed" pref (defaults to false)
- Makes ServiceWorkerContainer::Register to throw NS_ERROR_DOM_SECURITY_ERR if the
script url is a moz-extension url and the caller is a non-system caller
(but do not throw NS_ERROR_DOM_SECURITY_ERR if the caller is a moz-extension
and the new pref is set to true)
Depends on D60244
Differential Revision: https://phabricator.services.mozilla.com/D60245
- Adds the new about:config pref "extensions.backgroundServiceWorker.enabled" (currently defaults to false).
- Adds the background.service_worker property to the manifest JSON schema definition
- Locks background.service_worker manifest property behind the new preference
- Adds a new BackgroundWorker class to ext-backgroundPage.js (responsible for managing the background
service worker for the extension, e.g. make sure that the expected worker script is registered
as expected when the extension is starting up)
- Adds to the ServiceWorkerManager a new method to allow the WebExtension Framework to register the
background service worker without an existing extension page
- Allows the "moz-extension" schema in the dom/serviceworkers and dom/cache internals
Depends on D63697
Differential Revision: https://phabricator.services.mozilla.com/D60244
AHardwareBuffer is supported since Android O(APIVersion 26). Implementation of AndroidHardwareBufferTextureData referred AndroidNativeWindowTextureData. Implementation of AndroidHardwareBufferTextureHost referred obsoleted GrallocTextureHost.
android fence is not supported yet.
Differential Revision: https://phabricator.services.mozilla.com/D81808
This should be a relatively straightforward patch. Essentially, we implement
a wrapper class (and friends) around nsZipArchive (and friends), which transparently
caches entries from the underlying zip archive in the StartupCache. This will break
without changes to the StartupCache, made in the patch after this, which allow it
to be used off of the main thread, and outside the main process.
Depends on D77635
Differential Revision: https://phabricator.services.mozilla.com/D77634
Opening our Omnijars can be expensive, and it should be deferrable until after
startup is completed, provided we have a startup cache. In a previous patch in this
stack, we implemented caching of the zip central directory for omnijars, but we
still have to open the file in order to hand the object off to various omnijar
consumers. In a later patch, we will wrap nsZipArchive access in a class which
will allow us to transparently cache nsZipArchive results. These two get us
most of the way to not needing to read from the underlying omnijar files during
startup, but there are still nontrivial pieces, like nsZipFind for instance,
which we don't want to just duplicate inside of a wrapper class, so we would
like to sort out a way in which we can use an nsZipArchive class, but not
actually back it up with the real underlying file until we really need data
from it which we can't find in a cache.
Depends on D77633
Differential Revision: https://phabricator.services.mozilla.com/D78584
We would like to be able to defer opening the omnijar files until after startup
if the StartupCache has already been populated. Opening the omnijar files takes
a nontrivial time, at least on Windows, and almost everything in the omnijar
should be fairly compressible, and thus makes sense to live in the StartupCache.
See the last patch in this series for a little more discussion on numbers, but
tl;dr: we saw a 12% improvement in time to about:home being finished on reference
hardware with these changes together with the changes from the descendant patches.
Differential Revision: https://phabricator.services.mozilla.com/D77632
This should be a relatively straightforward patch. Essentially, we implement
a wrapper class (and friends) around nsZipArchive (and friends), which transparently
caches entries from the underlying zip archive in the StartupCache. This will break
without changes to the StartupCache, made in the patch after this, which allow it
to be used off of the main thread, and outside the main process.
Depends on D77635
Differential Revision: https://phabricator.services.mozilla.com/D77634
Opening our Omnijars can be expensive, and it should be deferrable until after
startup is completed, provided we have a startup cache. In a previous patch in this
stack, we implemented caching of the zip central directory for omnijars, but we
still have to open the file in order to hand the object off to various omnijar
consumers. In a later patch, we will wrap nsZipArchive access in a class which
will allow us to transparently cache nsZipArchive results. These two get us
most of the way to not needing to read from the underlying omnijar files during
startup, but there are still nontrivial pieces, like nsZipFind for instance,
which we don't want to just duplicate inside of a wrapper class, so we would
like to sort out a way in which we can use an nsZipArchive class, but not
actually back it up with the real underlying file until we really need data
from it which we can't find in a cache.
Depends on D77633
Differential Revision: https://phabricator.services.mozilla.com/D78584
We would like to be able to defer opening the omnijar files until after startup
if the StartupCache has already been populated. Opening the omnijar files takes
a nontrivial time, at least on Windows, and almost everything in the omnijar
should be fairly compressible, and thus makes sense to live in the StartupCache.
See the last patch in this series for a little more discussion on numbers, but
tl;dr: we saw a 12% improvement in time to about:home being finished on reference
hardware with these changes together with the changes from the descendant patches.
Differential Revision: https://phabricator.services.mozilla.com/D77632
As DMABuf is going to be used under X11 let's remove Wayland keyword from the preferences
and also use media.ffmpeg key.
Wayland specific preferences rename:
widget.wayland-dmabuf-textures.enabled to widget.dmabuf-textures.enabled
widget.wayland-dmabuf-webgl.enabled to widget.dmabuf-webgl.enabled
Change dmabuf preferences to media.ffmpeg ones:
widget.wayland-dmabuf-vaapi.enabled to media.ffmpeg.vaapi.enabled
widget.wayland-dmabuf-video-textures.enabled to media.ffmpeg.dmabuf-textures.enabled
Implement media.ffmpeg.vaapi-drm-display.enabled preference to use DRM VA-API display
instead of the native one.
Differential Revision: https://phabricator.services.mozilla.com/D81512
- Adds a new "extensions.serviceWorkerRegister.allowed" pref (defaults to false)
- Makes ServiceWorkerContainer::Register to throw NS_ERROR_DOM_SECURITY_ERR if the
script url is a moz-extension url and the caller is a non-system caller
(but do not throw NS_ERROR_DOM_SECURITY_ERR if the caller is a moz-extension
and the new pref is set to true)
Depends on D60244
Differential Revision: https://phabricator.services.mozilla.com/D60245
- Adds the new about:config pref "extensions.backgroundServiceWorker.enabled" (currently defaults to false).
- Adds the background.service_worker property to the manifest JSON schema definition
- Locks background.service_worker manifest property behind the new preference
- Adds a new BackgroundWorker class to ext-backgroundPage.js (responsible for managing the background
service worker for the extension, e.g. make sure that the expected worker script is registered
as expected when the extension is starting up)
- Adds to the ServiceWorkerManager a new method to allow the WebExtension Framework to register the
background service worker without an existing extension page
- Allows the "moz-extension" schema in the dom/serviceworkers and dom/cache internals
Depends on D63697
Differential Revision: https://phabricator.services.mozilla.com/D60244
Matthew Gaudet
Valentin Gosu
prathiksha
Molly Howell
James Willcox
Paul Adenot
Brian Birtles
Mark Striemer
Dale Harvey
Alex Chronopoulos
Randell Jesup
Frederik Braun
Michal Novotny
Sean Feng
Miko Mynttinen
Julian Descottes
Alexis Beingessner
Marco Bonardo
Dorel Luca
J.C. Jones
Kagami Sascha Rosylight
Bogdan Tara
Narcis Beleuzu
Dan Minor
Andrea Marchesini
Mihai Alexandru Michis
Butkovits Atila
Jeff Muizelaar
Chun-Min Chang
Kris Maglione
Csoregi Natalia
Jed Davis
Mark Banner
Dana Keeler
Michael Froman
Sebastian Streich
Mike Hommey
Doug Thayer
Andrew McCreight
Nicholas Nethercote
Perry Jiang
Emilio Cobos Álvarez
Hiroyuki Ikezoe
Christoph Kerschbaumer
Brindusan Cristian
Nils Ohlmeier [:drno]
Cosmin Sabou
Luca Greco
sotaro
Noemi Erli
Jeff Gilbert
Sebastian Hengst
Martin Stransky
Simon Giesecke