Now that WebGL runs on the Renderer thread in the compositor process
when OOP, we can now lift the threadsafe condition on Linux preventing
WebGL OOP. Regardless of webgl.out-of-process's setting, we should
always prefer by default to run worker WebGL contexts OOP to avoid
similar threadsafe conflicts in the content process.
Differential Revision: https://phabricator.services.mozilla.com/D129896
The preference should be enabled before rolling out "fission for authenticated sites"
to makes sure we have the permissions there when the feature is on.
Differential Revision: https://phabricator.services.mozilla.com/D127107
Right now, all high-value permissions have the same expiration time, but
we might want to set difference expiration time for different
high-value permission type in the future.
Differential Revision: https://phabricator.services.mozilla.com/D127106
The default size on most platforms is 256*256 which corresponds to the default blob tile size. I didn't check on android so I set it to 512*512 above which we never batch the upload so that the behavior is unchanged, but I suspect that a smaller threshold like 256*256 would also work better there.
On Windows with heavy blob image workloads, not batching gives a 20%-30% improvement to the time spent in update_texture_cache.
Differential Revision: https://phabricator.services.mozilla.com/D129516
Make it always false for now, as we still need a solution for
layout-dependent shorthands like margin, padding, border, etc.
Differential Revision: https://phabricator.services.mozilla.com/D130039
The preference should be enabled before rolling out "fission for authenticated sites"
to makes sure we have the permissions there when the feature is on.
Differential Revision: https://phabricator.services.mozilla.com/D127107
Right now, all high-value permissions have the same expiration time, but
we might want to set difference expiration time for different
high-value permission type in the future.
Differential Revision: https://phabricator.services.mozilla.com/D127106
And remove the autofill.background pref for 95 (or 96, depending on
when this lands) assuming nothing terrible causes us to turn it off on
94.
Differential Revision: https://phabricator.services.mozilla.com/D129988
Currently, soft reload uses the `VALIDATE_ALWAYS` flag to not only
force revalidate the top level document, but also subresources.
This causes content to be refetched from the web even if there
are caches that are still valid and can be used.
Chrome already has such behaviour to not revalidate all resources.
Differential Revision: https://phabricator.services.mozilla.com/D122270
CLOSED TREE
Backed out changeset 309190b4a49d (bug 1732792)
Backed out changeset 600e6dfd7436 (bug 1732792)
Backed out changeset 834441a08cc0 (bug 1733481)
Since we have fixed all compatibility bugs and dependencies, so let's
ship this attribute since all browsers already support this.
Differential Revision: https://phabricator.services.mozilla.com/D129229
To more properly support Linux having a different default at runtime.
Expose the resolved value in appinfo for convenience, and use it in the
front-end as needed.
Differential Revision: https://phabricator.services.mozilla.com/D129004
We use "is-in-chrome-docshell" rather than "is a chrome doc" so that about:
pages that are loaded in the content area (like about:addons etc) follow the
general content theme as well.
Cache the relevant color schemes since having that many branches on the default
system theme made me a bit uncomfortable, and this code can be called quite a
lot... Though it probably isn't such a huge deal. This makes us initialize the
theme right away, so make sure subclasses do the right thing. This in practice
was only an issue for GTK, which does cache the "system theme is dark" bit.
Differential Revision: https://phabricator.services.mozilla.com/D128674
This preference was requested by driver developers, simplifying
debugging processes. It is especially useful on Linux, but may
be handy on other platforms as well.
As a side effect it also ensures the two places with fallback paths
behave the same again on Android.
Depends on D128411
Differential Revision: https://phabricator.services.mozilla.com/D128592
If the BrowsingContext is missing in ConstructBrowser, previously we would fail
out, crashing the content process. With this new change, we instead exit
successfully, destroying the `ManagedEndpoint` instances due to the earlier
changes in this bug, and displaying the subframe as crashed.
As we don't know how to reproduce the case which caused this crash, this change
instead triggers the failure using a custom pref, which can be used to request
that attempts to create a BrowserParent for a specific BrowsingContext fail in
the same way as it would for a missing BrowsingContext, allowing us to test the
behaviour.
Differential Revision: https://phabricator.services.mozilla.com/D128778
Scaffolding: Add assertions everywhere execution currently depends on
a memory being a memory32. These assertions will disappear by and by.
Add some useful predicates and guard memory64 on !huge-memory.
Make it possible for the initial heap size to be a 64-bit value,
update WasmBCE.cpp to deal with this, and note in a comment that this
does not affect asm.js at all.
Exclude Cranelift and MIPS64 from memory64 in moz.configure; this
is extra work that does not pay off at this time.
Enable the inclusion of memory64 code by default in moz.configure.
Flip the about:config switch to false so that we can land in Nightly
without exposing content to m64 until we have completed Milestone 2.
Test cases are in the last patch in the queue.
Differential Revision: https://phabricator.services.mozilla.com/D124887
Scaffolding: Add assertions everywhere execution currently depends on
a memory being a memory32. These assertions will disappear by and by.
Add some useful predicates and guard memory64 on !huge-memory.
Make it possible for the initial heap size to be a 64-bit value,
update WasmBCE.cpp to deal with this, and note in a comment that this
does not affect asm.js at all.
Exclude Cranelift and MIPS64 from memory64 in moz.configure; this
is extra work that does not pay off at this time.
Enable the inclusion of memory64 code by default in moz.configure.
Flip the about:config switch to false so that we can land in Nightly
without exposing content to m64 until we have completed Milestone 2.
Test cases are in the last patch in the queue.
Differential Revision: https://phabricator.services.mozilla.com/D124887
Remove the follow-firefox-theme pref as now that's default everywhere,
and document better the behavior of the color-scheme property by
reworking and commenting the logic on it a bit.
Differential Revision: https://phabricator.services.mozilla.com/D128610
Given all our UI is using -moz-toolbar-prefers-color-scheme, this seems
like a more reasonable default nowadays. Allow for it to be
configurable via the existing pref.
Differential Revision: https://phabricator.services.mozilla.com/D128527
This stuff is now a no-op because the RequestContentRepaint message has a
higher priority than vsync.
Depends on D127033
Differential Revision: https://phabricator.services.mozilla.com/D127593
Bug 1731054 and bug 1708673 caused a performance regression.
We should disable the pref (on beta) to fix the regression while we investigate the causes.
Differential Revision: https://phabricator.services.mozilla.com/D128052
Synced FlushRendering() causes deadlock on Wayland.
Main thread is blocked at MessageChannel::WaitForSyncNotify() and it's not processing events from system.
Rendering thread is blocked at RendererOGL::UpdateAndRender() / eglQuerySurface(). Mesa is waiting for free back buffer
at get_back_bo(), it's spinning wl_display_roundtrip_queue() and waiting for free buffer but it doesn't get one as main loop is blocked.
Differential Revision: https://phabricator.services.mozilla.com/D127878
Now that windows is going to support dark colors, we want to make it
behave like other platforms in this regard.
Having a single pref for this seems better.
Differential Revision: https://phabricator.services.mozilla.com/D127624
For that:
* Tweak the standin system colors to match the non-native theme.
* Use those system colors for button and field backgrounds.
* Rename the "should use system colors" bit to "is high contrast",
which is what it really is (specially now that we use system colors
also in non-high-contrast).
Border colors and other colors like the <input type=range> and such
might need some extra tweaking perhaps, but this is a decent start and
looks good in https://crisal.io/tmp/form-controls.html afaict (dark mode
toggle needs the color-scheme pref enabled of course).
Differential Revision: https://phabricator.services.mozilla.com/D127533
In bug1692881, we introduced a mechanism to skip to next key frame if video decoding is too slow, which aims to help slow decoding issue on high resolution videos. Eg. 4k+.
However, there are some cases which would also lead to slow decoding. Eg. when internal seek (seek on one track only) happens on a place where we can't seek to directly, we need to seek to the previous keyframe and then decode all of them until we get the target frame.
That could lead to spending huge amount of time if the target frame is far from the keyframe, and causes decoded video frame later than the media time because audio won't stop playing during video seek. However, in above example, there would only be few frames later than the media time, and the video will soon catch up with the time.
As we only want to trigger this mechanism for continually slow decoding problem, and completely removing this mechanism would lead us fallback to the situation where some 4K+ videos would be frozen all the time during the playback.
In this patch, we introduce a method which still keep this mechanism but won't perform that as aggressive as before, this uses the time threshold to seek to the next keyframe when video has been late for too long.
Differential Revision: https://phabricator.services.mozilla.com/D126858
If amount of origins that have early-data disabled exceeds certain amount, disable early-data for all origins
This is controlled by prefs.
Differential Revision: https://phabricator.services.mozilla.com/D126555
There are a fair amount of performance and correctness issues that need
to be worked on, and at least I don't have the time to work on them
right now, so let's disable it until some of the issues blocking
bug 1578503 are fixed.
Differential Revision: https://phabricator.services.mozilla.com/D127085
We only draw a scrollbar thumb, so it's easy enough (fair amount of
boilerplate, though).
For now I've done the trivial thing (keep painting a round thumb without
other fancy things), as that's what we were doing, but in the future we
should consider drawing a stroke around the thumb like cocoa does to add
more contrast.
This patch does change behavior in some cases. For example dark websites
now get a lighter, easier to distinguish scrollbar, thanks to the
scrollbar darkening code in nsNativeBasicTheme.cpp.
Differential Revision: https://phabricator.services.mozilla.com/D125826
`enterkeyhint` defines action label to present the enterkey of virtual
keyboard.
Actually, This attribute and setter/getter support on WebKit and Blink.
Even if desktop browsers (WebKit/macOS, Blink/Windows, Blink/macOS and
Blink/Linux) cannot set the enter key label on virtual keyboard, this is
supported.
So I would like to ship this to all platforms.
If this value is changed on desktop browser, it is unaffected.
Differential Revision: https://phabricator.services.mozilla.com/D126171
We only draw a scrollbar thumb, so it's easy enough (fair amount of
boilerplate, though).
For now I've done the trivial thing (keep painting a round thumb without
other fancy things), as that's what we were doing, but in the future we
should consider drawing a stroke around the thumb like cocoa does to add
more contrast.
This patch does change behavior in some cases. For example dark websites
now get a lighter, easier to distinguish scrollbar, thanks to the
scrollbar darkening code in nsNativeBasicTheme.cpp.
Differential Revision: https://phabricator.services.mozilla.com/D125826
A couple of years ago we had observed that the way ANGLE emulated PBOs was slower than using glTexSubImage2D.
Since then ANGLE added a fast path which performs better, especially in frames with a large amount of pixels are uploaded.
Switching to PBOs on windows gives us better performance overall and will let us remove some code paths.
Differential Revision: https://phabricator.services.mozilla.com/D126697
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
We only draw a scrollbar thumb, so it's easy enough (fair amount of
boilerplate, though).
For now I've done the trivial thing (keep painting a round thumb without
other fancy things), as that's what we were doing, but in the future we
should consider drawing a stroke around the thumb like cocoa does to add
more contrast.
This patch does change behavior in some cases. For example dark websites
now get a lighter, easier to distinguish scrollbar, thanks to the
scrollbar darkening code in nsNativeBasicTheme.cpp.
Differential Revision: https://phabricator.services.mozilla.com/D125826
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
Right now adding a dynamic pref for webrender involves plumbing in gfxPlatform, gfxVars, CompositBridgeParent, WebRenderBridgeParent, WebRenderAPI, the bindings, and then messaging the pref change to the right thread in WebRender.
That's quite a bit time consuming for something we tend to do for multiple things.
We already have a pretty good system for boolean debug prefs where the pref only needs to be listed in gfxPlatform and in the DebugPref enum of webrender_api/lib.rs, which has led us to use it for non-debug purposes.
This patch adds a system similar to the DebugFlags with values passed in a bitfield to be able to use gfxVars. In WebRender the parameters are key-value pairs which flow through the pipeline so that any component can react to them. A followup will add integer parameters.
The patch also moves a few prefs to this system and adds a pref to use PBO uploads.
Differential Revision: https://phabricator.services.mozilla.com/D126100
If this pref is set, native layers will use a specialized video layer api for
fullscreen video content, which will reduce power consumption. It will do this
by isolating the fullscreen video layer from other layers. It may also remove
non-video content accompanying the fullscreen video. Content behind the video
*will* be replaced with a black fullscreen rectangle.
Future bugs will aim to reduce this side effect.
Differential Revision: https://phabricator.services.mozilla.com/D124999
We add scroll-timeline rule into the stylesheet rule type, and add a new
perference to protect it: layout.css.scroll-linked-animations.enabled.
We will use this perference for animation-timeline property as well.
Differential Revision: https://phabricator.services.mozilla.com/D125765
It looks like these were formatted wrong by mistake, and so the final `else` value in both instances was being used as the default value on all platforms.
Differential Revision: https://phabricator.services.mozilla.com/D125753
Add prefs:
* browser.sessionstore.dom_form_limit
Limit for how long a value from a form can be to be included in
session store collection.
* browser.sessionstore.dom_form_max_limit
Limit how much total data we collect from forms from one site, as in
the sum of length of values plus sum of length of xpath/id.
Differential Revision: https://phabricator.services.mozilla.com/D125195
Yury Delendik
Iulian Moraru
Csoregi Natalia
John Lin
Andrew Osmond
Dimi
Nicolas Silva
Sandor Molnar
Emily McDonough
Sebastian Hengst
Emilio Cobos Álvarez
Norisz Fay
Hiroyuki Ikezoe
sotaro
criss
Jeff Gilbert
Sean Feng
Alexandru Michis
Bryce Seager van Dyk
Shane Caraveo
Narcis Beleuzu
Marian-Vasile Laza
Luca Greco
Bob Owen
Makoto Kato
Gijs Kruitbosch
Denis Palmeiro
Valentin Gosu
Tim Chevalier
Butkovits Atila
Julian Descottes
Steve Fink
Manuel Bucher
Brad Werth
Jeff Muizelaar
Niklas Goegge
Robert Mader
Timothy Nikkel
Nika Layzell
msub2
Lars T Hansen
Markus Stange
Chris Peterson
Cosmin Sabou
Dragana Damjanovic
Kershaw Chang
Frederik Braun
Cristian Tuns
stransky
Sergey Galich
Randell Jesup
Jens Stutte
june wilde
Jon Bauman
alwu
Mike Hommey
Tetsuharu Ohzeki
Stephen A Pohl
Paul Adenot
Jonathan Kew
Benjamin VanderSloot
Micah Tigley
Junjie Ying
Noemi Erli
Boris Chiou
Morgan Reschenberg
Kris Wright
Florian Quèze
Tim Huang
Andreas Farre