This patch adds fetchpriority support for the `<img>` element, also
exposing the corresponding attribute in the WebIDL. As in D197493, we
try and minimize the change and rely on a mapping configurable under a
preference to ease future experiments. We use initial mapping
PRIORITY_LOW/PRIORITY_HIGH/PRIORITY_LOW for fetchpriority=low/high/auto
and allow further adjustments in the image code.
Internal fetchpriority mapping is covered by the following tests:
- `image-initial-load.h2.html` (typos fixed here)
- `image-dynamic-load.h2.html`
DOM tests are covered by the following tests (pref enabled to make them
pass):
- `idlharness.https.html`
- `attr-img-fetchpriority.html`
Differential Revision: https://phabricator.services.mozilla.com/D202222
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
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
Also fix opSetScriptLineAndColumnNumberAndFreeze::mColumnNumber to point the
first character of the script source, instead of '>' of the start tag.
Differential Revision: https://phabricator.services.mozilla.com/D193374
Also fix opSetScriptLineAndColumnNumberAndFreeze::mColumnNumber to point the
first character of the script source, instead of '>' of the start tag.
Differential Revision: https://phabricator.services.mozilla.com/D193374
The request priority isn't propagated from `ScriptFetchOptions`, so
setting it has no effect for end-users. That will be implemented in a
following part.
Differential Revision: https://phabricator.services.mozilla.com/D183483
Having it disabled is not web compatible, and there's no strong reason
to keep it, IMO.
If we want another pref to determine whether preloads are actually
triggered we can add it in the future.
Differential Revision: https://phabricator.services.mozilla.com/D186014
The request priority isn't propagated from `ScriptFetchOptions`, so
setting it has no effect for end-users. That will be implemented in a
following part.
Differential Revision: https://phabricator.services.mozilla.com/D183483
The request priority isn't propagated from `ScriptFetchOptions`, so
setting it has no effect for end-users. That will be implemented in a
following part.
Differential Revision: https://phabricator.services.mozilla.com/D183483
