This makes all platforms report video-dynamic-range:high if the screen
most closely associated with the document (according to the logic of
nsDeviceContext::FindScreen) is HDR capable.
This removes the LookAndFeel id for VideoDynamicRange, since it is only
used by Gecko_MediaFeatures_VideoDynamicRange, which is being modified
here to use the nsDeviceContext instead.
It also removes gfxPlatform::supportsHDR and its implementations, as it
is no longer used.
Differential Revision: https://phabricator.services.mozilla.com/D203329
Even though it supports adding preferences to JS Shell, I kept the custom
`--enable-json-parse-with-source` because it makes the shell-option flags very
slightly easier in jstests.
Differential Revision: https://phabricator.services.mozilla.com/D202615
Even though it supports adding preferences to JS Shell, I kept the custom
`--enable-json-parse-with-source` because it makes the shell-option flags very
slightly easier in jstests.
Differential Revision: https://phabricator.services.mozilla.com/D202615
Content processes will now always retarget delivery of OnDataAvailable for Http
channels off the main thread. Consumers that were previously redirecting
off-main thread are not affected and their retargeting will stick, but any
Httpchannel that was not retargeted off the main thread will be retargeted to
the nsIStreamTransportService.
If the listener for nsHTTPCompressConv cannot be called off the main thread (ie
the call to nsIRetargetableRequest::CheckListenerChain would fail),
nsHTTPCompressConv will be called off main thread but dispatch its decoded data
back to the main thread.
Differential Revision: https://phabricator.services.mozilla.com/D191377
Add preference for the proposal and implement to/from hex-string methods. The
initial implementation doesn't yet try to optimise allocations. For example as
a follow-up, we could directly allocate in the correct jemalloc arena instead of
first creating an intermediate `js::Vector`.
Differential Revision: https://phabricator.services.mozilla.com/D204636
This makes all platforms report video-dynamic-range:high if the screen
most closely associated with the document (according to the logic of
nsDeviceContext::FindScreen) is HDR capable.
This removes the LookAndFeel id for VideoDynamicRange, since it is only
used by Gecko_MediaFeatures_VideoDynamicRange, which is being modified
here to use the nsDeviceContext instead.
It also removes gfxPlatform::supportsHDR and its implementations, as it
is no longer used.
Differential Revision: https://phabricator.services.mozilla.com/D203329
Add preference for the proposal and implement to/from hex-string methods. The
initial implementation doesn't yet try to optimise allocations. For example as
a follow-up, we could directly allocate in the correct jemalloc arena instead of
first creating an intermediate `js::Vector`.
Differential Revision: https://phabricator.services.mozilla.com/D204636
Implement the style part for shape(). Besides, update some issues in the
test file, e.g. avoid using viewport height so we get the fixed result
on different devices.
I will refactor `PathCommand` to let it be a specialization of
`GenericShapeCommand` in the following path.
Differential Revision: https://phabricator.services.mozilla.com/D202882
Content processes will now always retarget delivery of OnDataAvailable for Http
channels off the main thread. Consumers that were previously redirecting
off-main thread are not affected and their retargeting will stick, but any
Httpchannel that was not retargeted off the main thread will be retargeted to
the nsIStreamTransportService.
If the listener for nsHTTPCompressConv cannot be called off the main thread (ie
the call to nsIRetargetableRequest::CheckListenerChain would fail),
nsHTTPCompressConv will be called off main thread but dispatch its decoded data
back to the main thread.
Differential Revision: https://phabricator.services.mozilla.com/D191377
Add a GC parameter and pref for semispace nursery which is disabled by default.
Enable it for the shell rootanalysis job to get get some test coverage.
Differential Revision: https://phabricator.services.mozilla.com/D196431
Instead of modifying SavePrefFile to do off-main-thread writing for
the non-nullptr case, I chose to create a new method dedicated to
writing to the non-default preference file for backing up. This
method will always use off-main-thread writing, unless the preference
service is configured to not allow that.
In either case, it'll return a Promise that resolves when the backup
file has been written.
This also fixes a bug where calling SavePrefFile with some nsIFile
wouldn't necessarily write to that file if there was a prior write
operation still being processed.
Differential Revision: https://phabricator.services.mozilla.com/D203832
Original work by Nika Layzell and Ted Mielczarek.
Of note:
- GLdouble and GLclampd are not defined in the iPhoneOS SDK opengl
headers.
- GL_CONTEXT_PROVIDER_DEFAULT was defined too early for
GLContextProviderEAGL to be used as intended.
- GLContextProviderEAGL::CreateForCompositorWidget was aligned with
GLContextProviderCGL::CreateForCompositorWidget. There is a ton of
overlap between both, but sharing more code was left out of scope.
- MacIOSurface::BindTexImage and
SurfacePoolCA::LockedPool::GetFramebufferForSurface were left
unimplemented.
- RootSnapshotter is disabled.
Differential Revision: https://phabricator.services.mozilla.com/D204323
Original work by Nika Layzell and Ted Mielczarek.
Of note:
- GLdouble and GLclampd are not defined in the iPhoneOS SDK opengl
headers.
- GL_CONTEXT_PROVIDER_DEFAULT was defined too early for
GLContextProviderEAGL to be used as intended.
- GLContextProviderEAGL::CreateForCompositorWidget was aligned with
GLContextProviderCGL::CreateForCompositorWidget. There is a ton of
overlap between both, but sharing more code was left out of scope.
- MacIOSurface::BindTexImage and
SurfacePoolCA::LockedPool::GetFramebufferForSurface were left
unimplemented.
- RootSnapshotter is disabled.
Differential Revision: https://phabricator.services.mozilla.com/D204323
If session history in the parent is enabled then session store only works
correctly if the platform collection code is turned on.
Differential Revision: https://phabricator.services.mozilla.com/D203375
These prefs don't do anything unless browser.sessionstore.platform_collection is
enabled, but we don't need the granularity that they provide. Let's just use
have the one browser.sessionstore.platform_collection pref control everything.
Differential Revision: https://phabricator.services.mozilla.com/D203374
Now that the touch activation duration no longer impacts the timing of
synthesized mouse events for single-tap gestures, increase the duration.
This should give users a better indication of element activation, without
negatively impacting performance.
Differential Revision: https://phabricator.services.mozilla.com/D204047
If setting Super Resolution is failed, it needs to be disable the next time.
pref gfx.webrender.super-resolution.nvidia is changed to a generic name gfx.webrender.overlay-vp-super-resolution
Differential Revision: https://phabricator.services.mozilla.com/D204172
Check the URLs in the request against the prefs
browser.contentanalysis.allow_url_regex_list and
browser.contentanalysis.deny_url_regex_list, which are space-separated
lists of ECMAscript regexs that match against ASCII-encoded URLs.
Differential Revision: https://phabricator.services.mozilla.com/D203508
This patch modifies the behaviour of loads when the DONT_RETARGET
nsIURILoader flag is set, making them ignore the Content-Disposition
header. This means that loads which cannot trigger downloads will
attempt to display handleable content which would otherwise be
downloaded.
This keeps overall behaviour of object/embed elements more similar to
their behaviour pre-Fission, while allowing them to load attachment PDFs
and Images as-if they were being displayed by a plugin.
This patch does not change the existing behaviour around
unknown/unhandleable resource types in object/embed elements.
In Gecko, object/embed elements are prevented from triggering downloads
or external protocol handlers during their initial load. Other browser
engines can trigger a download for an unknown resource type (or
sometimes an attachment resource).
The new pref dom.navigation.object_embed.allow_retargeting can be
enabled to instead trigger a download when loading these resources
within an object/embed element.
Differential Revision: https://phabricator.services.mozilla.com/D201645
When HttpChannelParent::OnRedirectResult is called with an error code,
CompleteRedirect would end up calling SendRedirectFailed, then soon after
we'd call redirectChannel->Delete()
RecvRedirectFailed() then calls mRedirectChannelChild->Cancel() which races
against the Delete called by the main proces.
Differential Revision: https://phabricator.services.mozilla.com/D203601
Check the URLs in the request against the prefs
browser.contentanalysis.allow_url_regex_list and
browser.contentanalysis.deny_url_regex_list, which are space-separated
lists of ECMAscript regexs that match against ASCII-encoded URLs.
Differential Revision: https://phabricator.services.mozilla.com/D203508
When HttpChannelParent::OnRedirectResult is called with an error code,
CompleteRedirect would end up calling SendRedirectFailed, then soon after
we'd call redirectChannel->Delete()
RecvRedirectFailed() then calls mRedirectChannelChild->Cancel() which races
against the Delete called by the main proces.
Differential Revision: https://phabricator.services.mozilla.com/D203601
chromium blocks it when driver is not 550.00+.
pref gfx.webrender.video-true-hdr.nvidia is changed to a generic name gfx.webrender.overlay-vp-auto-hdr
Differential Revision: https://phabricator.services.mozilla.com/D203568
This is not ideal, because they fall back to position the popup under
the cursor, but it's probably better.
The right thing to do would be for Windows to use the TITLEBARINFOEX
message. We should probably still land that code just so they can
eventually use it, seems worth doing anyways.
Differential Revision: https://phabricator.services.mozilla.com/D203423
This implements the basic infrastructure to use use libdbusmenu to
export the Linux menubar.
For now, this is not integrated with the front-end, and there are some
remaining bugs, so it lands disabled by default behind the
widget.gtk.global-menu.enabled pref.
Differential Revision: https://phabricator.services.mozilla.com/D200259
The implementation ended up not being terribly complex and even though
there's some compatibility risk (because align-content didn't use to
have an effect on blocks), chromium is on its way to ship this sooner
than us, so we'll find out if it's not compatible before this hits
release, if it isn't.
Differential Revision: https://phabricator.services.mozilla.com/D203156
Replace the part of WasmFeatures.h which would manually
read prefs through touching a bunch of Gecko stuff and
instead just use JSPrefs for that. Also use JSPrefs for
the shell instead of rolling our own shell flags. This
commit removes the 'stage' distinction because that only
changed how shell flags worked.
Differential Revision: https://phabricator.services.mozilla.com/D201869
This is Fantasai's original patch, massively simplified:
* We now can switch whether we're a BFC dynamically (bug 1765615), which
simplifies the patch quite a lot.
* I removed some changes that were specific to pagination but were untested.
I left them as D202814, just in case we need some of those in the future.
All in all this makes the patch much more manageable.
Co-authored-by: Emilio Cobos Álvarez <emilio@crisal.io>
Differential Revision: https://phabricator.services.mozilla.com/D181858
This patch adds fetchpriority support for `<link rel=preload as=image>`
and equivalent HTTP Link header. The fetchpriority value is passed from
where the link is parsed down to `NewImageChannel` where the priority
is initially set. Currently, the default equals PRIORITY_LOW, but is
decreased a bit if LOAD_BACKGROUND flag is set (this is always the case
for link preload images, see `imgLoader::LoadImage`). Later, the
priority can be increased again depending on the category (see
`imgRequest::BoostPriority`).
In order to minimize the changes, the new calculation is to keep the
initial setting to PRIORITY_LOW, adjust it using a new
`network.fetchpriority.adjustments.*` preference depending on the
fetchpriority attributes, and then preserve further adjustments for
LOAD_BACKGROUND and `BoostPriority`.
For the default value `fetchpriority=auto`, there is no adjustment
i.e. we continue to start with PRIORITY_LOW. `fetchpriority=low/high`
are respectively mapped to PRIORITY_LOW/PRIORITY_HIGH which is simple
and consistent with the "Image" cases from Google's web.dev article
https://web.dev/articles/fetch-priority. These values could of course
be revised in the future after more experiments.
This change is covered by the following tests below. The expectations
is modified to match what is described above (i.e. map to PRIORITY_LOW
or PRIORITY_HIGH with adjustment due to LOAD_BACKGROUND):
- `link-initial-preload-image.h2.html`
- `link-dynamic-preload-image.h2.html`
- `kPipeHeaderPreloadImageLinks`
Based on a patch by Mirko Brodesser (mbrodesser@igalia.com)
Differential Revision: https://phabricator.services.mozilla.com/D197493
This patch adds fetchpriority support for `<link rel=preload as=image>`
and equivalent HTTP Link header. The fetchpriority value is passed from
where the link is parsed down to `NewImageChannel` where the priority
is initially set. Currently, the default equals PRIORITY_LOW, but is
decreased a bit if LOAD_BACKGROUND flag is set (this is always the case
for link preload images, see `imgLoader::LoadImage`). Later, the
priority can be increased again depending on the category (see
`imgRequest::BoostPriority`).
In order to minimize the changes, the new calculation is to keep the
initial setting to PRIORITY_LOW, adjust it using a new
`network.fetchpriority.adjustments.*` preference depending on the
fetchpriority attributes, and then preserve further adjustments for
LOAD_BACKGROUND and `BoostPriority`.
For the default value `fetchpriority=auto`, there is no adjustment
i.e. we continue to start with PRIORITY_LOW. `fetchpriority=low/high`
are respectively mapped to PRIORITY_LOW/PRIORITY_HIGH which is simple
and consistent with the "Image" cases from Google's web.dev article
https://web.dev/articles/fetch-priority. These values could of course
be revised in the future after more experiments.
This change is covered by the following tests below. The expectations
is modified to match what is described above (i.e. map to PRIORITY_LOW
or PRIORITY_HIGH with adjustment due to LOAD_BACKGROUND):
- `link-initial-preload-image.h2.html`
- `link-dynamic-preload-image.h2.html`
- `kPipeHeaderPreloadImageLinks`
Based on a patch by Mirko Brodesser (mbrodesser@igalia.com)
Differential Revision: https://phabricator.services.mozilla.com/D197493
Intended as an escape valve and diagnosis tool in case someone has a device
setup that is troublesome with VPIO on macOS.
Differential Revision: https://phabricator.services.mozilla.com/D202405
This is to add basic fetch priority support. It introduces preference of
fetch priority adjustment as per to recent discussions. We need to refine the
fetchpriority mapping taking into account of destination, which will be
addressed in Bug 1881040.
In addition, this changes the relervant prefs type to atomic type to accommodate
the access of the prefs off the main thread in the worker case.
Differential Revision: https://phabricator.services.mozilla.com/D200778
Intended as an escape valve and diagnosis tool in case someone has a device
setup that is troublesome with VPIO on macOS.
Differential Revision: https://phabricator.services.mozilla.com/D202405
Previously, we used an undefined (and thus hidden) pref, making it more difficult to toggle.
Also, we used GetBoolPref, which is slightly less efficient.
But mostly, this is just cleaner.
Differential Revision: https://phabricator.services.mozilla.com/D202383
It is hard to predict reasonable values here. Sorting costs n*log2(n) comparisons and refptr swaps where n is the total number of cache entries. If we assume to be able to purge max. 10% of them, sorting a minimum of 32*10 entries takes 320*log2(320) ~= 2660 loop cycles. On the other hand 32 purges translate to probably 64 memory free operations, each of which might write a poison value block of max. 64 bytes each (see bug 1850008), resulting in a total write of 4096 bytes scattered on 64 memory locations plus some overhead for updating the hashtable.
For lower n nothing bad can happen, and for significantly higher n the sorting will always be the heavier part.
Differential Revision: https://phabricator.services.mozilla.com/D202171
It is disabled in this patch via the gfx.canvas.remote.allow-offscreen
pref. A follow up patch will enable this by default.
Differential Revision: https://phabricator.services.mozilla.com/D189532
This patch makes us block on the DOM worker thread in order to
synchronize properly with canvas 2D recordings when toDataURL and toBlob
are called on an HTMLCanvasElement object which also called
transferControlToOffscreen and transferred it to a DOM worker.
Differential Revision: https://phabricator.services.mozilla.com/D202286
This patch modifies the behaviour of loads when the DONT_RETARGET
nsIURILoader flag is set, making them ignore the Content-Disposition
header. This means that loads which cannot trigger downloads will
attempt to display handleable content which would otherwise be
downloaded.
This keeps overall behaviour of object/embed elements more similar to
their behaviour pre-Fission, while allowing them to load attachment PDFs
and Images as-if they were being displayed by a plugin.
This patch does not change the existing behaviour around
unknown/unhandleable resource types in object/embed elements.
In Gecko, object/embed elements are prevented from triggering downloads
or external protocol handlers during their initial load. Other browser
engines can trigger a download for an unknown resource type (or
sometimes an attachment resource).
The new pref dom.navigation.object_embed.allow_retargeting can be
enabled to instead trigger a download when loading these resources
within an object/embed element.
Differential Revision: https://phabricator.services.mozilla.com/D201645
This patch modifies defaults of `network.fetchpriority.adjustments.*`
preferences so that internal priority of `fetchpriority=auto` to matches
when `network.fetchpriority` is disabled (i.e. adjustment is 0) and
the extra minimal changes to ensure the order of internal priority values
for high, auto and low is unchanged. That way the current default
behavior for fetchpriority unspecified/auto won't change when we enable
the flag. We may decide to depart from that in the future though.
Differential Revision: https://phabricator.services.mozilla.com/D202065
This introduces preferences loading style. See D201997 for the
rationale, test coverage and why there is no behavior change.
Note that current behavior for deferred style is to always set
PRIORITY_LOW, so the fetchpriority attribute has no effect.
Some preference names could be more verbose to match the if
branches in `Loader::AdjustPriority` but note that it is not
clear whether "deferred preload style" can actually happen,
see bug 1879335.
Differential Revision: https://phabricator.services.mozilla.com/D202052
This introduces preferences <link rel=preload as=font/fetch>.
See D201997 for the rationale, test coverage and why there is no
behavior change.
Differential Revision: https://phabricator.services.mozilla.com/D202047
This introduces preferences for non-link scripts. See D201997 for the
rationale, test coverage and why there is no behavior change.
Differential Revision: https://phabricator.services.mozilla.com/D202046
The fetchpriority attribute allows web developers to request some
adjustment to the internal priorities when fetching resources. In order
to give some flexibility for experimenting and choosing the values that
work best for Gecko, we will introduce new preferences to control
exactly how the internal priority is adjusted, depending on the value
auto/high/low of the fetchpriority attribute.
This is the first patch of a series introducing such preferences,
focusing on the case `<link rel=preload as=script>`. The following 3
integer preferences are introduced:
```
network.fetchpriority.adjustments.link-preload-script.low
network.fetchpriority.adjustments.link-preload-script.high
network.fetchpriority.adjustments.link-preload-script.auto
```
and are set so that we don't change current behavior (already
covered by tests). A test is also added to verify basic invariants
for such adjustments.
Differential Revision: https://phabricator.services.mozilla.com/D201997
The purpose of this pref is to avoid breaking any tests that don't expect a
HTTPS record to be present. For example, if you're loading http://domain.com
in a test, and don't expect a HTTPS upgrade to happen, if that domain suddenly
adds a HTTPS record we might end up upgrading to HTTPS even in automation.
This pref does an early return with NS_ERROR_UNKNOWN_HOST just before doing
a call to the system API. This means we're still waiting in the DNS queue to
resolve the domain (simulating the same waiting times we might see
on users' computers), but we never actually use native DNS to resolve a HTTPS
record in automation.
Differential Revision: https://phabricator.services.mozilla.com/D200785