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
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 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
In bug 1866277 we aligned internal priority of
`<link rel=preload as=fetch>` when `network.fetchpriority` is disabled
with the case of `fetchpriority=auto` (PRIORITY_HIGH), effectively
exposing a behavior change in M124. This commit restores the previous
behavior when `network.fetchpriority` is disabled (PRIORITY_NORMAL)
and instead aligns `fetchpriority=auto` with that value.
Differential Revision: https://phabricator.services.mozilla.com/D201944
This commit aligns the internal priority of <link rel=preload as=fetch>
when fetchpriority support is disabled with the fetchpriority=auto case
when the support is enabled. Also aligns unreachable code in
LinkRelPreloadFetch with that value.
Differential Revision: https://phabricator.services.mozilla.com/D199877
Renames all instances of the snake_case identifier to
camelCase to match more closely to idiomatic JavaScript
and to existing conventions throughout the code base.
Differential Revision: https://phabricator.services.mozilla.com/D198826
This is somewhat complex, untested, never shipped, and predates
fission.
Remove it to simplify the code.
Depends on D198183
Differential Revision: https://phabricator.services.mozilla.com/D198184
Previously it may have been possible in some edge cases for us to send
`MaybeFireEmbedderLoadEvents` for a non-toplevel frame during docshell
tree teardown.
Differential Revision: https://phabricator.services.mozilla.com/D197825
This adds code to emit ETW markers on windows. It supports all current
markers through a generic marker emitting schema. It also supports
additional payload and filtering for any markers that are updated to a
new compile-time marker schema system. Because of our abstraction layer
and cross-platform nature we have to manually create the TraceLogging
structs used and can't rely on their macro's, but this should give us a
very flexible and performant marker implementation on ETW.
Differential Revision: https://phabricator.services.mozilla.com/D196331
Previously, for `rel=preload as=fetch`, the internal priority,
`nsISupportsPriority`, was not adjusted. Now, the adjustment happens in
`FetchPreloader::CreateChannel`.
For `rel=preload as=font`, previously, the internal priority was always
set to high in `FontLoaderUtils::BuildChannelSetup`. Now, the internal
priority is a parameter, whose value potentially depends on the
`fetchpriority` attribute.
Note the minor correction of calling `SetPriority` instead of
`AdjustPriority` in `FontLoaderUtils::BuildChannelSetup`.
Differential Revision: https://phabricator.services.mozilla.com/D194205
To record whether we have detected suspicious fingerprinting activities
to the ContentBlockingLog, we introduce a new ContentBlockingLog event
called STATE_BLOCKED_SUSPICIOUS_FINGERPRINTING.
Whenever a fingerprinting content blocking event gets recorded under an
origin, we check if this origin is conducting suspicious fingerprinting
activites. Then, we store this fact under the origin entry and notify
the STATE_BLOCKED_SUSPICIOUS_FINGERPRINTING event to indicate that there
is a suspicous fingerprinitng activity happening.
I need to move ContentBlockingLog::RecordLogInternal() from header to
cpp file to avoid include file dependency issue.
Differential Revision: https://phabricator.services.mozilla.com/D193454
