Do this by spinning the event loop until we've done the clone for
preview as appropriate.
This should be much less risky than finishing the previous patches
which would still be nice, but realistically landing them for 81 is not
going to happen.
This just returns without doing nothing in a couple cases, like when
there's already another modal dialog or such. That seems acceptable to
me, it's not clear what better way to do would be.
Differential Revision: https://phabricator.services.mozilla.com/D87484
To keep PDFJS's mechanism to setup default prefs from overriding values
defined in all.js, I had to add a check to see if the pref is already
defined.
Differential Revision: https://phabricator.services.mozilla.com/D87009
With these changes, there are still a number of test failures when remote
object/embed is enabled, due to svg sizing and resource timing tests. In order
to land these changes before those features are fixed, it will be placed behind
a pref.
Differential Revision: https://phabricator.services.mozilla.com/D86582
This adds a thread count for GC parallel tasks calculated from GC parameters
for a helper thread ratio and max helper thread count. It also adds one to
report the number of helper threads used for GC.
This is slightly complicated by the fact that the helper thread system is
per-process and there are potentially many JS runtimes in a process. I
disallowed setting these parameters from workers (i.e. child JS runtimes), but
there may be more than one non-worker JS runtime so this isn't perfect.
I had to swap the mutex order for the GC and helper thread locks. Whatever
reason they were the other way round seems to have gone and this order makes
more sense to me (I see the GC lock as being 'coarser' than the helper thread
lock).
Differential Revision: https://phabricator.services.mozilla.com/D86725
This table is only in debug builds, but it takes up about 100kb,
so it sticks out in DMD reports taken in debug builds.
Differential Revision: https://phabricator.services.mozilla.com/D87347
This adds a thread count for GC parallel tasks calculated from GC parameters
for a helper thread ratio and max helper thread count. It also adds one to
report the number of helper threads used for GC.
This is slightly complicated by the fact that the helper thread system is
per-process and there are potentially many JS runtimes in a process. I
disallowed setting these parameters from workers (i.e. child JS runtimes), but
there may be more than one non-worker JS runtime so this isn't perfect.
I had to swap the mutex order for the GC and helper thread locks. Whatever
reason they were the other way round seems to have gone and this order makes
more sense to me (I see the GC lock as being 'coarser' than the helper thread
lock).
Differential Revision: https://phabricator.services.mozilla.com/D86725
This is strictly better and more flexible, but can change specificity so
have a pref in case it causes trouble. I doubt it will though, the
specificity rules of :is() make more sense, and my gut feeling is that
:-moz-any is not very used on the wild.
Make it early-beta-or-earlier for now to minimize risk, once this is on
nightly for a bit we can enable it everywhere.
Differential Revision: https://phabricator.services.mozilla.com/D86696
We want this to be turned on for nightly users by default. The page range is still a WIP,
so we should hide that section for now.
This also adds the pref to the "Nightly Experiment" panel, turned on by default.
Differential Revision: https://phabricator.services.mozilla.com/D85907
In bug1654045, we would stop controlling media once media reaches to the end. Considering some user might still want to control media by pressing media keys even if it has ended, so adding a pref to control this abilitiy.
Differential Revision: https://phabricator.services.mozilla.com/D85930
The deactivation timer introduces an uncertainty of when user can control media, but instead of removing that, I want to add a pref to control it and disable it by default because I can still think of some benefit of this ability.
Differential Revision: https://phabricator.services.mozilla.com/D85928
Include stdio.h before redefining ftello and fseeko to avoid clobbering the ftello() and fseeko() function declarations in MinGW's stdio.h.
I don't know why my change to compile libmar as C11 (bug 1653182) caused this ftello/fseeko problem. From my inspection of MinGW's stdio.h, this problem should have already been happening!
Differential Revision: https://phabricator.services.mozilla.com/D85665
It was disabled on nightly in bug 1636998. It does nothing anymore.
There's no regression known and I'm hoping we can get rid of it.
Differential Revision: https://phabricator.services.mozilla.com/D85208
This adds a profiler-stats.txt file to captures that dumps the profiler
stats, if those are being recorded. They get recorded if the profiler is
visible, or if the (newly added) PROFILER_CAPTURE debug option is enabled.
Differential Revision: https://phabricator.services.mozilla.com/D85592
This adds a profiler-stats.txt file to captures that dumps the profiler
stats, if those are being recorded. They get recorded if the profiler is
visible, or if the (newly added) PROFILER_CAPTURE debug option is enabled.
Differential Revision: https://phabricator.services.mozilla.com/D85592
This is the first of what will likely be a couple patches for
cross-fade's implementation. Bug 546052 tracks it's complete
implementation.
Differential Revision: https://phabricator.services.mozilla.com/D81889
* always update the opaque region if the toplevel window allocation
changes - this fixes opaque regions on X11 with WR and OGL renderers,
as GTK resets the opaque region in this case. The previous solution
was modeled similar to what's done on Windows - we have to follow GTK
though.
* use `gdk_window_set_opaque_region` also for Wayland - this fixes
occasional glitches where the opaque region was not properly updated.
Let GTK handle that instead, as it has better control of the internals.
* remove a failed attempt to work around bug 1615098 from
MozContainerWayland
* repurpose `widget.wayland.use-opaque-region` for subsurface opaque
regions and disable it by default. We want to enable it again eventually
and not all Wayland compositors suffer from bug 1615098
* some cleanups - some optimizations should not be needed anymore now
Unfortunately this does not cover the classic title bar yet - that will
need to be done in a follow-up.
Differential Revision: https://phabricator.services.mozilla.com/D84024
static_assert is available in both C++11 and C11. While C++11's static_assert is a keyword, C11's static_assert is a macro defined in assert.h (that expands to the C11 keywoard _Static_assert). libar's header files are included in both C and C++ code, so we must #include assert.h to use static_assert.
https://en.cppreference.com/w/c/language/_Static_assert
Differential Revision: https://phabricator.services.mozilla.com/D83736
This is the first of what will likely be a couple patches for
cross-fade's implementation. Bug 546052 tracks it's complete
implementation.
Differential Revision: https://phabricator.services.mozilla.com/D81889
The pref will have no effect if the compile-flag isn't set, but this can confuse
some users who will see the pref in about:config.
Differential Revision: https://phabricator.services.mozilla.com/D83422
It could go into its own test suite, but it 1) depends on `mozbuild` code, so the `mozbuild` suite as well as this new suite would be running on any push that touches `mozbuild` code anyway, and 2) this is code that runs during the build, so it's not out of place.
Differential Revision: https://phabricator.services.mozilla.com/D84547
It could go into its own test suite, but it 1) depends on `mozbuild` code, so the `mozbuild` suite as well as this new suite would be running on any push that touches `mozbuild` code anyway, and 2) this is code that runs during the build, so it's not out of place.
Differential Revision: https://phabricator.services.mozilla.com/D84547
This effectively reverts bug 1549965 and disables the GPU
process on Linux. We would only turn it on with OpenGL and
WebRender compositing, which was for half of nightly users,
and 1-2% of release users.
See bug 1653444 for a list of bugs blocking re-enabling
the GPU process on Linux.
Differential Revision: https://phabricator.services.mozilla.com/D83871
I could have use apz.allow_zooming but using a separate pref means we can flip the pref to check if the new scrollbar code is the source of a regression. Also I haven't tested the code on Fenix at all, so we can disable it there for now.
Differential Revision: https://phabricator.services.mozilla.com/D82684
It could go into its own test suite, but it 1) depends on `mozbuild` code, so the `mozbuild` suite as well as this new suite would be running on any push that touches `mozbuild` code anyway, and 2) this is code that runs during the build, so it's not out of place.
Differential Revision: https://phabricator.services.mozilla.com/D84547
This patch adds the UI for allowing users to enable reporting XFO error.
The reporting UI will be displayed in the error page if the error is a
XFO error.
Differential Revision: https://phabricator.services.mozilla.com/D82331
media.videocontrols.picture-in-picture.video-toggle.mode controls the toggle variation.
Valid values are -1 (default, what we currently ship), 1 and 2.
media.videocontrols.picture-in-picture.video-toggle.position controls the toggle variation
position. Valid values are "left" and "right" (default).
Differential Revision: https://phabricator.services.mozilla.com/D84032
* Use clearer pref names.
* Default (and only support) IPDL dispatching.
* Make DispatchCommands async-only.
* Sync ipdl command per sync webgl entrypoint.
* Eat the boilerplate cost, since there's not too many.
* Run SerializedSize off same path as Serialize.
* All shmem uploads go through normal DispatchCommands.
* Defer pruning of dead code for now so we can iterate quickly.
* Use Read/Write(begin,end) instead of (begin,size).
* This would have prevented a bug where we read/wrote N*sizeof(T)*sizeof(T).
Differential Revision: https://phabricator.services.mozilla.com/D81495
This avoids problems where a foreground tab tries to communicate with a background
tab via `window.opener`, but is unable to because the background tab
is suspended.
Differential Revision: https://phabricator.services.mozilla.com/D83693
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
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
This patch adds the boolean pref mathml.stixgeneral_operator_stretching.disabled, which defaults to true iff nightly.
When the pref is true, stretched operators won’t be rendered with STIXGeneral, because we only use OpenType MATH tables (in fonts that have them) or the generic Unicode table.
When the pref is false, we continue to support STIXGeneral for stretched operators, but warn the author in devtools and bump the use counter (up to once per page). This only happens when a stretched operator actually uses STIXGeneral: not when we successfully render the operator with some other font earlier in the font-family stack, and not when STIXGeneral isn’t installed.
Differential Revision: https://phabricator.services.mozilla.com/D73833
On mobile platform, "ENTER" key on software keyboard key can sometimes
change to "Next" and etc. Although Firefox OS/Firefox Android have
`mozactionhint` attribute for its behaviour, This is standardized version
of it.
Chrome and Safari already support it now, so I would like to support this
on Firefox/GeckoView Nightly.
Differential Revision: https://phabricator.services.mozilla.com/D79641
Severin
Emilio Cobos Álvarez
Brendan Dahl
Noemi Erli
Jeff Gilbert
Nika Layzell
Jon Coppeard
Andrew McCreight
Zeke Medley
Kartikaya Gupta
Shinichi Morimoto
Denis Palmeiro
Andrea Marchesini
Bogdan Tara
Mihai Alexandru Michis
Adam Vandolder
Lars T Hansen
alwu
Csoregi Natalia
Dragana Damjanovic
Butkovits Atila
Valentin Gosu
Martin Stransky
Nils Ohlmeier [:drno]
Simon Giesecke
Emma Malysz
Sonia Singla
John Dai
Anny Gakhokidze
Matt Woodrow
Chris Peterson
Randall E. Barker
Hiroyuki Ikezoe
Julien Cristau
Robert Mader
Stephen A Pohl
Tom Schuster
Brindusan Cristian
Alexander Surkov
Sebastian Streich
Dorel Luca
Ryan Hunt
Tim Nguyen
Timothy Nikkel
Ricky Stewart
Andrew Osmond
prathiksha
Narcis Beleuzu
Tim Huang
Mike Conley
Michael Kaply
James Willcox
Gijs Kruitbosch
Eugen Sawin
Matthew Gaudet
Molly Howell
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
J.C. Jones
Kagami Sascha Rosylight
Dan Minor
Jeff Muizelaar
Chun-Min Chang
Kris Maglione
Jed Davis
Mark Banner
Dana Keeler
Michael Froman
Mike Hommey
Doug Thayer
Nicholas Nethercote
Perry Jiang
Christoph Kerschbaumer
Cosmin Sabou
Luca Greco
sotaro
Sebastian Hengst
Paul Bone
Jonathan Kew
Tom Tung
Erik Nordin
Delan Azabani
Jason Laster
Marcos Cáceres
Tom Tung
Razvan Maries
Makoto Kato
Markus Stange
Nihanth Subramanya
Kershaw Chang