The Firefox in flatpak has no access to the wireless networks to determine
accurate geolocation. We have to use the location portal instead which
provides the current location based on the nearby wireless accesspoints
or other methods.
Differential Revision: https://phabricator.services.mozilla.com/D142329
The Firefox in flatpak has no access to the wireless networks to determine
accurate geolocation. We have to use the location portal instead which
provides the current location based on the nearby wireless accesspoints
or other methods.
Differential Revision: https://phabricator.services.mozilla.com/D142329
Put mozilla.widget.raise-on-setfocus, widget.transparent-windows
and widget.wayland.use-move-to-rect in StaticPrefList.yaml, then
get rid of gRaiseWindows, gTransparentWindows and gUseMoveToRect
from widget/gtk/nsWindow.cpp.
Differential Revision: https://phabricator.services.mozilla.com/D143885
When downloading a file, we check for existing mime types and construct
a new one if it's unrecognized. Mime types have a flag,
alwaysAskBeforeHandling, that determines whether the unknown content
type dialog should be opened before handling the file. Before bug
1733492, the default value for that flag was simply true. Since the new
downloads flow is intended to avoid unnecessary steps, the default value
was changed to the inverted value of the new downloads panel
improvements pref. This patch adds a new pref that the mime info
constructor will read in configuring the flag's value. If the
improvements pref is not enabled, then the flag will be true, so the UCT
dialog will open. If the improvements pref is enabled, then it'll use
the value of the new pref. Also add a an interface for the pref to the
about:preferences UI, and automatically migrate a false value for
browser.download.improvements_to_download_panel to a true value for this
pref. I'm updating some tangentially related test files since they
happen to be touched slightly by this change. Strictly speaking they
would still work, but if the pref value was somehow changed from the
default they would fail.
Differential Revision: https://phabricator.services.mozilla.com/D143002
We did it for early-beta in bug 1632143, for nightly even earlier. No
regressions in two years, sounds like flipping is warranted.
Differential Revision: https://phabricator.services.mozilla.com/D143496
This sets up prefs so by default any release will use the content signature path
for GMP updates, rather than cert pinning. This intentionally leaves in place
the old cert pinning machinery so that we can still use if we need to
- Compare the new and old for things like debugging.
- Revert these changes in the case of regressions (either by shipping a patch or
something like normandy).
This patch is also small to enable it to be uplifted easily.
Once we're sure this new path is good, a larger patch can follow up to remove
the cert pinning code + rework our tests.
Differential Revision: https://phabricator.services.mozilla.com/D141891
When downloading a file, we check for existing mime types and construct
a new one if it's unrecognized. Mime types have a flag,
alwaysAskBeforeHandling, that determines whether the unknown content
type dialog should be opened before handling the file. Before bug
1733492, the default value for that flag was simply true. Since the new
downloads flow is intended to avoid unnecessary steps, the default value
was changed to the inverted value of the new downloads panel
improvements pref. This patch adds a new pref that the mime info
constructor will read in configuring the flag's value. If the
improvements pref is not enabled, then the flag will be true, so the UCT
dialog will open. If the improvements pref is enabled, then it'll use
the value of the new pref. Also add a an interface for the pref to the
about:preferences UI, and automatically migrate a false value for
browser.download.improvements_to_download_panel to a true value for this
pref. I'm updating some tangentially related test files since they
happen to be touched slightly by this change. Strictly speaking they
would still work, but if the pref value was somehow changed from the
default they would fail.
Differential Revision: https://phabricator.services.mozilla.com/D143002
This patch extends the expiration time of the storage access permission
given by the redirect heuristic to 30 days. This matches to the
expiration time of the permission given by other heuristics.
Differential Revision: https://phabricator.services.mozilla.com/D142431
To support magnifying glass on GeckoView, I would like to add `dragcaret`
event and, clientX and clientX in CaretStateChangedEvent chrome event.
Actually, accessible caret fires `presscaret` and `releasecaret` when
accessbile caret is pressed or released. But when dragging this caret, no
chrome event is fired. Since magnifying glass listens to moving this caret,
I would like `dargcaret` for GeckoView.
Also, Users' dragging point is necessary to set better position of magnifying
glass windows. So I also want client point of dragging point on `presscaret`
and `dragcaret` event.
This event and properties are on layout.accessiblecaret.magnifier.enabled=true,
So this can be only for GeckoView.
Differential Revision: https://phabricator.services.mozilla.com/D137965
This should reduce our memory footprint by no longer requiring us to
fully rasterize SVG images when used as an image map. It should also
move the cost of rasterization off the main thread during display list
building to worker threads during scene building.
Differential Revision: https://phabricator.services.mozilla.com/D143190
This proxies the printing operation via the parent like we do everywhere
else.
Otherwise we try to create anonymous files in the child process which is
forbidden.
Differential Revision: https://phabricator.services.mozilla.com/D142971
Bug 1753146 doubled the success threshold for Windows only, but browser/base/content/browser-gestureSupport.js at https://searchfox.org/mozilla-central/rev/26a1b0fce12e6dd495a954c542bb1e7bd6e0d548/browser/base/content/browser-gestureSupport.js#739 multiplies the values present in swipe events by 4 to determine opacity; so it it assuming the value 0.25 is the success threshold.
This patch first reverts bug 1753146 and then fixes it in a different way, so that the success threshold still has the same value and hence we don't need to modify browser-gestureSupport.js (so that all the code depending on this is in one one). We double the kWholePagePixelSize on Windows (and turn it into a pref) so that we don't regress bug 1753146. This is equivalent because the numeric value computed in SwipeTracker::ComputeSwipeSuccess will be the same, since the values mGestureAmount and mCurrentVelocity all have a division by kWholePagePixelSize when they are computed in SwipeTracker::ProcessEvent. There is one difference though: the velocity twitch tolerance comparison in SwipeTracker::ComputeSwipeSuccess will be slightly different. I think that's okay though.
Differential Revision: https://phabricator.services.mozilla.com/D140185
WMFDecoderModule will now cache supported stream types upon decoder process startup. Only one task will be dispatched to the MTA thread where all support will be determined at once.
MFTDecoder now will call all functions necessary to fully free memory on its WMF objects.
Preference media.wmf.vp9.enabled can now be changed without restarting.
Differential Revision: https://phabricator.services.mozilla.com/D142002
Given that we only support samesite lax/strict/none in our storage schema,
it's useful to introduce a default value, as required by the spec.
However, that would it hard to distinguish between none/lax when we switch
the default.
So, instead of doing that we use the peculiarities of our current schema
to our advantage: There's a "sameSite" attribute and a "rawSameSite"
attribute, where the latter is the literal value we received from the
server. With this patch, we'll interpret the "sameSite" attribute
based on the laxByDefault pref. This also has the advantage that various
front-end code (e.g., in DevTools) is always reading the "sameSite"
value of nsICookies.
Differential Revision: https://phabricator.services.mozilla.com/D137460
This adds OnEvent hooks to DrawTargetWebgl for various events so that
profile counters may be maintained each frame. These profile counters
try to determine if a software fallback happened or an uncacheable event
occurs that requires either uploading data to the GPU or reading back
from the GPU, events which can cause substantial slowdown if they happen
repeatedly even without an explicit fallback to software rasterization.
When it is determined a threshold has been reached (as controlled by
some prefs), RequiresRefresh() in PersistentBufferProvider is used to
signal that we should recreate the PersistentBufferProvider of a different
type and thus disable acceleration.
Differential Revision: https://phabricator.services.mozilla.com/D142646
WMFDecoderModule will now cache supported stream types upon decoder process startup. Only one task will be dispatched to the MTA thread where all support will be determined at once.
MFTDecoder now will call all functions necessary to fully free memory on its WMF objects.
Preference media.wmf.vp9.enabled can now be changed without restarting.
Differential Revision: https://phabricator.services.mozilla.com/D142002
Two noteworthy details that may seem random otherwise:
* Moving values around in nsStyleDisplay is needed so that the struct
remains under the size limit that we have to avoid jumping allocator
buckets.
* All the test expectation churn is because tests depend on
`container-type: size` parsing to run, and now they run. Tests for
the relevant bits I implemented are passing, with the only exception
of some `container-name-computed.html` failures which are
https://github.com/w3c/csswg-drafts/issues/7181. Safari agrees with
us there.
Other notes when looking at the spec and seeing how it matches the
implementation:
* `container` syntax doesn't match spec, but matches tests and sanity:
https://github.com/w3c/csswg-drafts/issues/7180
* `container-type` syntax doesn't _quite_ match spec, but matches tests
and I think it's a spec bug since the definition for the missing
keyword is gone:
https://github.com/w3c/csswg-drafts/issues/7179
Differential Revision: https://phabricator.services.mozilla.com/D142419
This patch extends the expiration time of the storage access permission
given by the redirect heuristic to 30 days. This matches to the
expiration time of the permission given by other heuristics.
Differential Revision: https://phabricator.services.mozilla.com/D142431
Make Link and SVGAElement agree on XLink handling, and make it more
explicit that SVGAElement needs to be a bit more special for SMIL.
Remove dead MathML XLink code.
Differential Revision: https://phabricator.services.mozilla.com/D142546
Add media.rdd-process.max-crashes preference value to control how many times we restard RDD process before we throw decoding error message.
Differential Revision: https://phabricator.services.mozilla.com/D142326
The Baseline Requirements no longer require an OCSP URI for EV certificate
intermediates. Since OneCRL covers intermediates anyways, OCSP checking for
intermediates can be skipped entirely.
Differential Revision: https://phabricator.services.mozilla.com/D142369
Given that we only support samesite lax/strict/none in our storage schema,
it's useful to introduce a default value, as required by the spec.
However, that would it hard to distinguish between none/lax when we switch
the default.
So, instead of doing that we use the peculiarities of our current schema
to our advantage: There's a "sameSite" attribute and a "rawSameSite"
attribute, where the latter is the literal value we received from the
server. With this patch, we'll interpret the "sameSite" attribute
based on the laxByDefault pref. This also has the advantage that various
front-end code (e.g., in DevTools) is always reading the "sameSite"
value of nsICookies.
Differential Revision: https://phabricator.services.mozilla.com/D137460
This patch replaces the previous process selection infrastructure with a
new setup implemented entirely in C++, which should more accurately
track the set of processes in use, and should encourage re-use of the
existing content process when navigating by not counting the current
tab.
This approach intentionally allows for process switching to another
process during navigation if there is uneven load between processes to
encourage balanced process use.
I think this may also fix some of the session restore issues with many
tabs using the same process, rather than being spread over 4, as we now
track a tab earlier in its lifecycle before the BrowserParent instance
is created.
Differential Revision: https://phabricator.services.mozilla.com/D126405
Depends on D141468
All usage of this preference should now have been removed.
We don't plan to disable devtools completely, but only to disable the F12 shortcut.
Differential Revision: https://phabricator.services.mozilla.com/D141469
The patch adds two prefs to control whether we ignore the less
restricted referrer policies for top navigation. For Web compatibility,
we still need to allow less restricted referrer policies for top
navigations. We will allow it in the standard mode and still disallow it
in the strict mode and private browsing window.
Differential Revision: https://phabricator.services.mozilla.com/D141866
Depends on D141468
All usage of this preference should now have been removed.
We don't plan to disable devtools completely, but only to disable the F12 shortcut.
Differential Revision: https://phabricator.services.mozilla.com/D141469
They are just convenience for :root[lwthemetextcolor="light"] (and dark,
respectively), but they generally shouldn't be used for dark mode
theming. In the past it was the only way to do it but now we have
prefers-color-scheme.
While at it, change lwthemetextcolor to be "lwtheme-brighttext" for
consistency with similar code we have for popups etc, and move it to
_setDarkModeAttributes.
While at it, remove layout.css.moz-lwtheme.content.enabled (which is
false always, we unshipped these from content successfully).
Differential Revision: https://phabricator.services.mozilla.com/D141593
I think it's fair to say that this is not a new feature anymore. This avoids
showing the notification every time a developer uses devtools on a local build
or so (with a clean profile).
Differential Revision: https://phabricator.services.mozilla.com/D142000
The reason why we change the `OMTAdiv`'s width value is that with the original
200px width, the elment in question will be overflowed in our mochitest iframe.
Differential Revision: https://phabricator.services.mozilla.com/D141812
* TextEncoder stream tests now fail, rather than error
* WritableStreams are exosed on worker interfacess now; and broken-then is fixed too
* Fix interface semantics
Differential Revision: https://phabricator.services.mozilla.com/D141125
This patch just adds the plumbing to allow for baked in blocklist rules
or the downloadable blocklist to prevent certain configurations from
getting WebGPU. It does not add any rules.
It also changes us from allowing WebGPU only in nightly, including
tests, to not release and not beta. This allows try to run the WebGPU
tests as expected, since even try builds forked from mozilla-central are
not considered nightly builds by CI (or so it seems).
Differential Revision: https://phabricator.services.mozilla.com/D141682
Firefox background tasks use a new temporary profile directory for
every invocation. We would like to write as little data as possible
into the temporary profile directory in this mode. This patch allows
to make the persistent cookie storage discard cookies just like
private cookie storage.
This approach simply uses that the base `CookieStorage` class is close
to sufficient already. There may be a performance impact with more
virtual invocations, but none of these functions seem likely to be
hot.
Differential Revision: https://phabricator.services.mozilla.com/D139910
This allows themes to override our light / dark theme heuristics if they
choose to, so that we don't have to complicate the heuristics too much.
This is specially useful for themes with images, where the image might
be "light", but still have enough contrast with light text. A good
example is the theme mentioned in bug 1749837 comment 0.
The semantics are:
* color_scheme: If set, overrides the general "toolbar theme" (so
window and context menu appearance and so on), otherwise we fall back
to heuristics.
* content_color_scheme: If set, overrides the color scheme for the
content area. Otherwise we fall back to color_scheme if present, or
heuristics otherwise.
One thing that I didn't include was a sort of "system" option, which
might be useful to say "this theme is neutral, and works both for light
and dark themes". Let me know if you think that's a must-have, otherwise
I think it's probably worth deferring to a follow-up if it's needed at
all.
Differential Revision: https://phabricator.services.mozilla.com/D136354
This Nimbus experiment code was added in bug 1719070 to test if sending a "Firefox 100" UA string causes any major webcompat problems.
The moz.build change was added in bug 1724635 to fix a Thunderbird build break. MOZ_BUILD_APP_IS_BROWSER = true when building Firefox, false when building Thunderbird.
Differential Revision: https://phabricator.services.mozilla.com/D126408
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
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 removes the pref `security.csp.enable` and amends various callers
in dom/, which no longer have to take this pref into consideration.
Furthermore, we can remove the test in dom/base/test/browser_bug593387.js
The test used the pref to test that external content can be embedded into
about:plugins, which is historic baggage from a previous architecture of
said page that we no longer require. It's also an anti-pattern that we
do not want to support any longer. In fact, the test had to jump through
additional hoops to make that work at all.
Differential Revision: https://phabricator.services.mozilla.com/D138661
We might want to do this on Windows 11 as well, but Windows 11 has a
system-wide preference with UI so let's not do that just yet at least,
UI-exposed preference.
Differential Revision: https://phabricator.services.mozilla.com/D138502
Within DrawTargetWebgl, this implements a SharedContext class to store both the WebGL context and
also related resources for drawing with it. Not a lot of new code has actually been added as this
was mostly accomplished by refactoring as much drawing code as possible that touched the WebGL
context to be moved into SharedContext, while leaving any code that was only dealing with Skia
software rasterization still within DrawTargetWebgl itself as well as individual framebuffer state
that is unique to each DrawTargetWebgl instance.
Before DrawTargetWebgl can use SharedContext to draw, it must use SetTarget to install its framebuffer
as the one that the WebGL context will draw to as well as to learn details about the viewport and
other per-framebuffer state. All of the high-level cache state that was previously on DrawTargetWebgl
has now moved into SharedContext, so that SharedContext can easily access this for drawing as well
as to provide for the goal of simplifying resource limiting.
Differential Revision: https://phabricator.services.mozilla.com/D138117
Within DrawTargetWebgl, this implements a SharedContext class to store both the WebGL context and
also related resources for drawing with it. Not a lot of new code has actually been added as this
was mostly accomplished by refactoring as much drawing code as possible that touched the WebGL
context to be moved into SharedContext, while leaving any code that was only dealing with Skia
software rasterization still within DrawTargetWebgl itself as well as individual framebuffer state
that is unique to each DrawTargetWebgl instance.
Before DrawTargetWebgl can use SharedContext to draw, it must use SetTarget to install its framebuffer
as the one that the WebGL context will draw to as well as to learn details about the viewport and
other per-framebuffer state. All of the high-level cache state that was previously on DrawTargetWebgl
has now moved into SharedContext, so that SharedContext can easily access this for drawing as well
as to provide for the goal of simplifying resource limiting.
Differential Revision: https://phabricator.services.mozilla.com/D138117
This patch adds a pref "signon.usernameOnlyForm.formThreshold" to limit
the number of form we processed while receiving "PWMGR_NUM_FORM_HAS_POSSIBLE_USERNAME_EVENT_PER_DOC"
event. This improves the performance while loading a page with multiple username-only likely form.
Differential Revision: https://phabricator.services.mozilla.com/D138121
This patch adds a pref "signon.usernameOnlyForm.formThreshold" to limit
the number of form we processed while receiving "PWMGR_NUM_FORM_HAS_POSSIBLE_USERNAME_EVENT_PER_DOC"
event. This improves the performance while loading a page with multiple username-only likely form.
Differential Revision: https://phabricator.services.mozilla.com/D138121
The `media.clockdrift.buffering`'s type was set to signed integer when
introducing `AudioDriftCorrection` in Bug 1637234 (D74884), but the
buffering type of the `AudioDriftCorrection` was changed to unsigned in
Bug 1656438 (D89777). The `media.clockdrift.buffering` should be updated
to the unsigned integer as well.
Differential Revision: https://phabricator.services.mozilla.com/D138378
This is designed to mitigate the problem of third-party fonts that render poorly
under DirectWrite's bold simulation, by using multi-strike synthetic bold (like
we use on macOS) instead.
The behavior is controlled by a pref, so that we can readily switch between
using DWrite's bold simulation for all fonts (pref=2, our current behavior);
using it only for installed fonts and falling back to multi-strike for webfonts
(pref=1, new behavior); or never using the DWrite simulation (pref=0).
Differential Revision: https://phabricator.services.mozilla.com/D137584
This is faster and more straight-forward code than the old
ShouldUseDarkScrollbar shenanigans, and allows to have dark-themed
scrollbars.
Differential Revision: https://phabricator.services.mozilla.com/D138077
This is designed to mitigate the problem of third-party fonts that render poorly
under DirectWrite's bold simulation, by using multi-strike synthetic bold (like
we use on macOS) instead.
The behavior is controlled by a pref, so that we can readily switch between
using DWrite's bold simulation for all fonts (pref=2, our current behavior);
using it only for installed fonts and falling back to multi-strike for webfonts
(pref=1, new behavior); or never using the DWrite simulation (pref=0).
Differential Revision: https://phabricator.services.mozilla.com/D137584
Firefox version 100 will ship on 2022-05-03. The Webcompat team can use Firefox's site interventions to spoof a version 99 UA for individual sites broken by a three-digit version number. But Firefox’s site interventions can’t override the UA for enterprise intranet sites we don't know about.
This patch adds a new "network.http.useragent.forceVersion" pref that enterprise admins can set to a known-good UA version (like 99) in an enterprise policy file. If the pref has a non-zero value, then override the User-Agent string's Firefox version. The value 0 means use the default Firefox version.
We can remove this pref in Firefox 103 after the next ESR is branched (version 102 on 2022-06-28). Enterprise users can use ESR 102 with forceVersion pref = 99 until the next ESR in mid-2023. Hopefully they can fix their broken intranet sites by that time.
Differential Revision: https://phabricator.services.mozilla.com/D137929
This is designed to mitigate the problem of third-party fonts that render poorly
under DirectWrite's bold simulation, by using multi-strike synthetic bold (like
we use on macOS) instead.
The behavior is controlled by a pref, so that we can readily switch between
using DWrite's bold simulation for all fonts (pref=2, our current behavior);
using it only for installed fonts and falling back to multi-strike for webfonts
(pref=1, new behavior); or never using the DWrite simulation (pref=0).
Differential Revision: https://phabricator.services.mozilla.com/D137584
Currently we filter preferences sent to the content process when they are updated,
but do not apply this filter to the initial serialization of preferences. This
adds a filter function as an argument to SerializePreference that allows for the
caller to control which preferences are serialized.
Differential Revision: https://phabricator.services.mozilla.com/D137474
We don't actually want to fail requests that time out. So if the retry
also times out we just fallback to native as usual.
Depends on D137931
Differential Revision: https://phabricator.services.mozilla.com/D137932
This patch adds a partial OffscreenCanvasRenderingContext2D
implementation. It is missing anything text and UI related, including
CanvasFilters, CanvasUserInterface, CanvasText, CanvasTextDrawingStyles,
and CanvasHitRegions.
Differential Revision: https://phabricator.services.mozilla.com/D135354
This patch adds a partial OffscreenCanvasRenderingContext2D
implementation. It is missing anything text and UI related, including
CanvasFilters, CanvasUserInterface, CanvasText, CanvasTextDrawingStyles,
and CanvasHitRegions.
Differential Revision: https://phabricator.services.mozilla.com/D135354
This patch adds a partial OffscreenCanvasRenderingContext2D
implementation. It is missing anything text and UI related, including
CanvasFilters, CanvasUserInterface, CanvasText, CanvasTextDrawingStyles,
and CanvasHitRegions.
Differential Revision: https://phabricator.services.mozilla.com/D135354
"media.ondevicechange.fakeDeviceChangeEvent.enabled" does not change any
devices and so will not generate any events if/when no-op devicechange events
are filtered out.
The test is rearranged to reduce the wait for no event and run some steps in
parallel, so that the test runs in half the time. This benefit will
accumulate as more scenarios are added to the test.
Differential Revision: https://phabricator.services.mozilla.com/D132906
This allows for faster playback rates of EME media. This should allow up to ~5
times speed. Users in the wild have reported this value working without bustage,
so we have some evidence this is a safe value.
Differential Revision: https://phabricator.services.mozilla.com/D137563
This doesn't change behavior by default, but should allow users to tweak
them and provide feedback as to which scroll speed is better for them.
It seems for some people at least the current speed is too much. The
"pixel" mode I implemented should behave exactly like GNOME web, in
terms of scroll speed.
Differential Revision: https://phabricator.services.mozilla.com/D137472
Monitor Firefox 100 experiment enrollment in the parent process. If the user gets enrolled in the experiment, the parent process will set the forceVersion100 pref in other processes. The forceVersion100 pref can also be set by the "Firefox 100" option in the Nightly Experiments settings.
Chrome has a similar chrome://flags/#force-major-version-to-100 flag for testing a Chrome 100 UA.
Differential Revision: https://phabricator.services.mozilla.com/D135315